In message: <[EMAIL PROTECTED]>
"Seth Goodman" <[EMAIL PROTECTED]> writes:
>
>Bouncing spam after acceptance is a real problem, even though false
>positives would still get a DSN. The problem is that in the majority of
>spam, both the MAIL FROM: and the From: addresses are forged. Sending a
>bounce just abuses innocent third parties, in addition to giving the spammer
>a second chance to get their payload delivered.
Unfortunately, bouncing spam after acceptance is increasingly unavoidable
for anyone who has a backup MX host as insurance against their primary
host being down. Many spammers are targetting the secondary MX instead
of the primary MX... and a secondary MX sufficiently isolated from the
primary to actually be useful as a failover is likelyly to just accept,
queue, and relay. When the primary then rejects the message from the
secondary, the secondary is stuck trying to deliver a DSN.
I'm currently working on a hack to postfix such that locally-generated
DSN messages cannot get deferred (the RFC says that you must generate
a DSN, but doesn't say that you have to try to deliver it more than once).
This will at least prevent my secondary MX from crumbling under the load
of bouncing spam sent to nonexistant addresses on my 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.)
- Alex, peeved at having to hack his mail server because of the spammers
PS. No, I'm not willing to not have a secondary MX. My primary does
crash occasionally, though (thankfully) not as much as it used to
before I replaced the motherboard.
_______________________________________________
spambayes-dev mailing list
spambayes-dev@python.org
http://mail.python.org/mailman/listinfo/spambayes-dev
