On 3/6/2005 3:25 AM, Matt Kettler wrote:
> These days spamming is done via botnets
That's already trapped by sbl+xbl.
> Adding TLS shouldn't slow them down much, as it's mostly a CPU hit to
> do so...
There's a lot of stuff involved, and there's lots of things to score on.
Here's a couple of samples from DNSOps and Namedroppers:
from darkwing.uoregon.edu (darkwing.uoregon.edu [128.223.142.13])
(using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits))
(Client CN "darkwing.uoregon.edu", Issuer "Thawte Server CA"
(verified OK))
by goose.ehsco.com (Postfix ) with ESMTP
for <[EMAIL PROTECTED]>; Fri, 4 Mar 2005 02:18:17 -0600 (CST)
Received: from psg.com (psg.com [147.28.0.62])
(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
(Client did not present a certificate)
by goose.ehsco.com (Postfix ) with ESMTP
for <[EMAIL PROTECTED]>; Sat, 5 Mar 2005 16:16:15 -0600 (CST)
Did the client present it's own cert? Is it in a trusted path (not
self-signed)? Was there an revocation lookup? How tough was the key, and
how many bits were used (and scale the score accordingly)? So getting to
the higher cumulative scores wouldn't be very simple, and it would also
provide a clear path of responsibility, etc.
The same thing could be done with user-certs too, if a plug-in to SA wants
to do the verification testing.
There's also a possibility of having a generic GOOD_BOY set of meta SMTP
tests that give a bonus score if they all successfully match against good
administrative practives (such as HELO=RDNS). I'm still thinking about
this one; the 'professional marketers' would hit this a lot, and there's
too many poorly-run networks, so it might be counter-productive.
--
Eric A. Hall http://www.ehsco.com/
Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
