I had one of our guys write a quick report on businesses that offer a backup MX service. Attached is what he found out earlier today.
--- Puryear Information Technology, LLC Baton Rouge, LA * 225-706-8414 http://www.puryear-it.com Author: "Best Practices for Managing Linux and UNIX Servers" "Spam Fighting and Email Security in the 21st Century" Download your free copies: http://www.puryear-it.com/publications.htm Thursday, September 28, 2006, 4:47:06 PM, you wrote: > Robert Brockway wrote: >> On Wed, 27 Sep 2006, Daniel Feenberg wrote: >> >>> So, do you bounce any undeliverable queued messages from the primary >>> server when it comes back up? It seems like there is a serious >>> problem if you do >> >> >> Hi Daniel. The primary MTA certainly does bounce undeliverable mail >> (in accordance with the RFCs). > And, unfortunately, you end up blacklisted. Granted, I don't agree with > it either, but that's just how bad things have become. > The problem here is "backscatter". It's a common technique for spammers > now to send mail that they know _will not_ deliver, in the hopes that > you will bounce it back to the spoofed sender. >>> (you are spamming) and if you don't (legitimate senders are not >>> informed of >> >> >> Maybe I'm being thick but I can't see how this constitutes a problem, >> let alone spam. > http://spamlinks.net/prevent-secure-backscatter.htm >> Whether or not the primary MX bounces undeliverable mail back is >> entirely independent of whether the mail item was relayed through q >> secondary MX or not. A mail item destined for one of my domains could >> pass through any number of MTAs, one of which could be my backup MX, >> and my primary MX will deal with it the same way. Ergo any problems >> present on the primary MX will be independent of the presence of a >> backup MX in the recipient domain. >> >> Consider two emails A and B with the same sender and recipient. Mail >> item A travels directly from the sender's MTA to my primary MX where >> it bounces as there is no such user. Now consider mail item B which >> is sent when my primary MX is down. It queues on the secondary MX and >> it delivered to the primary MX later. The primary MX bounces B just >> as it did A. > As long as your secondary MX is forwarding it along to your primary MX, > it's the primary MX that will be rejecting the message, and the > secondary MX will then send the bounce. > If you're running the secondary MX for a customer in that instance, > you're the one sending the backscatter. (as Johnathan said). > A secondary MX shouldn't accept mail for domains it is not ready to > bounce mail for. Moreover, a secondary MX really shouldn't accept mail > for addresses that don't exist. > Ideally, a secondary does a username lookup via LDAP or connects to a > primary and verifies that the email is indeed correct via something like > "milter-ahead" (if you're using sendmail). > If a primary goes down, however, how is a secondary to know what > addresses are valid unless it has a full list of valid users? In this > case, should you simply accept everything for your customer's domains, > but refuse to bounce anything to prevent backscatter? > Once upon a time, bouncing was appropriate. This is no longer the case. > When did backscatter become considered "spam"? Apparently just in this > past year or so. > - Ian C. Blenke <ian at blenke.com> http://ian.blenke.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: BackupMXServices.pdf Type: application/pdf Size: 15215 bytes Desc: not available Url : /pipermail/general_brlug.net/attachments/20060928/1afc2bb0/attachment-0001.pdf
