Robert L Cochran wrote: > Just by way of commentary -- I'll have to find a backup mail > server some day -- perhaps with a friend living far away who > keeps a machine on 24X7. I wonder how many businesses and > individuals went without backup mail service when the power > went out in New York. Just my two cents on this... 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. 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? 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. 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! 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) 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. 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... 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 -- Shrike-list mailing list Shrike-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/shrike-list
