[spambayes-dev] sb_mailsort.py status

[Seth Goodman]

> From: T. Alexander Popiel [mailto:popiel at wolfskeep.com]
> 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