> From: T. Alexander Popiel [mailto:[EMAIL PROTECTED] > Sent: Monday, January 10, 2005 4:36 PM
<...> > Unfortunately, bouncing spam after acceptance is increasingly unavoidable > for anyone who has a backup MX host as insurance against their primary > host being down. Anyone who runs a secondary MX with less security than the primary, i.e. no list of real mailboxes, no FCrDNS, etc., might as well drop their anti-spam measures on the primary, because: > Many spammers are targetting the secondary MX instead of the primary > MX... as would anyone who wants to deliver a message that you don't want to accept and therefore seeks out the MX with the weakest security. > and a secondary MX sufficiently isolated from the primary to actually > be useful as a failover is likelyly to just accept, queue, and relay. It is perfectly reasonable to establish a secondary in another facility that still has the same list of real mailboxes and the same incoming policy as the primary. This might rule out some providers of backup MX services, but not all. If you're a large operation, you should have complete control over your secondary. If you're a small operation, you might want to rethink if it is really necessary to have a secondary MX if it is not possible to clone the setup of your primary. Hardware and network connections are more reliable than they used to be and senders will queue your mail upon temporary failures. > When the primary then rejects the message from the > secondary, the secondary is stuck trying to deliver a DSN. This is exactly the situation you never want to be in. A spammer should get the same rejection at your secondary that they get at your primary. <...> > (These spam DSNs frequently end up deferred because the purported > source either doesn't exist or issues a 400-series response to > trying to deliver the DSN... and the retries of these deferrals for > 4 days is what pushes my secondary over the edge.) Another possibility is that the systems to whom you are sending bogus DSN's are teergrubing you (forcing you to keep a socket and process alive for a long time) as punishment for abuse. Check your logs to see if these 4xx transactions are taking a very long time. Operating any MX in store and forward mode and sending out DSN's to return addresses on spam that you haven't confirmed are good during the SMTP session can easily turn you into a spam reflector. Even if the envelope return addresses on spam are valid, they are likely to be joe-job forgeries, so you still don't want to send DSN's in response to spam. -- Seth Goodman _______________________________________________ spambayes-dev mailing list spambayes-dev@python.org http://mail.python.org/mailman/listinfo/spambayes-dev
