On Sat, 2003-08-23 at 23:18, Cowles, Steve wrote: > Unless overidden, most MTA's default configurations will try to deliver > e-mail for 5 days. So configuring a backup MX for your domain will not > necessarily help until after the fifth day of outage. Key point, "unless overridden". BTW, I think the default is 3 days. > Even with a backup MX, you still have to consider the following: > > 1) If the backup MX is configured to simply relay e-mail to the primary (as > I showed in my reply to this thread), it too, will try to deliver to the > primary MX for 5 days. If unsuccessful, the backup MX server will issue the > same non-deliverable DSN's back to the original sender. So what have you > really gained by implementing a backup MX that only relays to the primary? Nothing, too much, is to be gained if mail is being delivered at the primary MX host. However, as pointed out earlier, the normal way things are done is having the MX hosts in your DMZ and they in turn relay the mail to an internal system. Additionally, even if you have your primary MX host as the delivery machine please consider 1) chances are you won't let it stay down for 1 day let alone 5 days and 2) having the second MX host makes you a good neighbor in that it takes mail off sending MTA's disk and puts them close to home. > With this in mind, the best way to configure a backup MX is to accept (and > store) all e-mail in a single mailbox for that domain. The primary MX will > then retreive (and deliver locally) the e-mail from the backup MX when it > comes back on-line through a cronjob or manually issuing an ETRN. This way, > no DSN is sent to the original sender. IMHO, this is an unnecessary hack and yet another "special" to be maintained. > 2) To further complicate matters.... if your primary MX is configured to use > RBL's or filters like Spamassassin and/or Antivirus software, then keeping > these configurations in sync is a royal pain in the ass. Especially if the > backup MX is at a remote site and adminsitered by a friend (so to speak). > Trust me, spammers have picked up on MTA's not being configured identically > and purposely use MTA's that deliver e-mail to the backup MX without first > trying the primary MX. Why? Because the primary MX is typically configured > to unconditionally accept all e-mail from the backup MX. Even if you were to > configure the primary to NOT accept all e-mails from the backup, you stand a > chance of creating a mail loop between the primary and secondary. (e.g. > Primary rejects e-mail from a spammer, then tries to deliver to the backup > MX. The backup MX server receives this e-mail and relays back to the > primary. The primary then rejects the e-mail again and again and again until > the MTA's hop limit is reached. Oh what fun! Sorry, I don't see the difficulty in keeping MX host's policies in sync. I worked on a project for a multi-national company with its own internal network. They had MX hosts spread over several countries to ensure prompt delivery of mail even if one country lost its Internet connection. Granted, this is an extreme case and we are probably talking about single location entities. Yet, doing consistent system administration should be a practice. > 3) The administration nightmare continues for those with backup MX's... > Suppose a spammers MTA is configured to only deliver to the backup MX (very > likely) and this inbound e-mail makes it past the backup MX's RBL checks (if > configured). Now consider the primary has deleted a local user account. The > backup MX (not knowing the local user list of the pirmary) relays the e-mail > to the primary, the primary accepts this e-mail, but then rejects it with a > "user unknown" and issues a DSN back to a forged reply-to, or better yet... > an MTA that will not accept DSN's. (e.g. rfc-ignorant.org listed) What you suggest only happens with shoddy system administration. > I can go on and on about these types of issues reagrding implementing a > backup MX. In fact, there have been many discussions lately on MTA lists > about this very topic and the need to implement a backup MX in the first > place considering that most MTA's will try to deliver for five days. Unless > you administer both the primary and backup MX server, you are in for some > administration nightmares if you implement a backup MX. Sounds like a lazy man's argument. :-) :-) > FWIW: I have implmented a backup MX for my domains. In fact, my backup MX is > also located in another state not administered by me. In order to resolve > the above mentioned problems; myself and the backup MX admin had to... You have pointed out the error in your ways. You have implemented a backup MX host over which you have no control. Bad practice, plain and simple. > 1) Use the same MTA (postfix) configured to reject connections that violate > invalid HELO's, non FQDN's for both sender and recipient addresses, non FQDN > for MTA's, etc... > > 2) We configured our MTA's to use the same RBL lists. > > 3) We configured each MTA to NOT run filters like Spamassassin or Antivirus > software when our MTA's accept e-mail for each others domains in a backup MX > mode. > > 4) We keep our MTA's local user lists replicated to each others MTA's so > that both the primary and backup MX will reject with the same "User Unknown" > DSN. > > Long pause... > > OK, after rereading this, I guess I added more than two cents. :-) > > Steve Cowles -- http://www.shorewall.net Shorewall, for all your firewall needs -- Shrike-list mailing list Shrike-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/shrike-list
