On Wed, 12 Jan 2005, Chris Drake wrote:
I don't see how SES might help here, btw: nothing I can do is going
to prevent these dumb MTAs from spewing their backscatter at me - at
least I already know it's all spam (my envelope senders are custom
and unique; no DSN's ever arrive to any normal user address)
Then you are doing SES. That is the core principal:
ensuring that envelope senders are custom and unique, and that no
(legitimate) DSN's ever arrive to any normal user address.
The SES project is simply working on improved replay protection -
the weakest point of SES - so that SES can be used for authentication
as well as blocking backscatter. (If a spammer gets one of your
unique envelope senders, it only lets them spam you - not worth the
effort since they need to spam millions. BUT, if they get a unique sender
used for authentication, they can use it to forge mail that passes
the authentication - without some form of replay protection.
As for rules: if the incoming envelope sender is <> and the RCPT TO:
doesn't exist; it's a backscatter problem for sure: there's no doubt a
simple way to add to the sendmail.cf and/or sendmail.mc files to
produce a custom 5xx error for these; sorry I'm too busy to figure it
out for you's!
I detect this in my sendmail milter (http://bmsi.com/python/milter.html)
and issue this DSN:
self.setreply('550','5.7.1',
"I did not send you that message. Please consider implementing SPF",
"(http://spf.pobox.com) to avoid bouncing mail to spoofed senders.",
"Thank you."
)
Detection is somewhat involved. If you don't want to provide free dictionary
search to spammers, then you don't want to REJECT immediately on
RCPT TO for normal recipients. I set a flag and REJECT after SMTP DATA
for backscatter. Not ideal, but workable.
--
Stuart D. Gathman <stuart(_at_)bmsi(_dot_)com>
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flamis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.