[PLUG] Spam, Etc.

[Ed Sawicki]

On Sun, 2003-06-22 at 18:45, Jason Van Cleve wrote:
> I see.  So it actually sounds a little more like the personal
> certificate idea to me now.  Except instead of validating emails, we'd
> be validating SMTP relays.  How would it work, though?  Would the relay
> have to sign all outgoing emails, or how would we verify the cert's?

Since none of this exists yet, I'll speculate how it could work
without changes to the SMTP protocol. It would require changes
to the way mail daemons work. Once the TCP three-way handshake
is over, the originating mail server would say EHELO but also
supply a certificate along with its name. The mail server that
was just contacted now validates the certificate. If the
certificate is OK, it responds in the usual way - with a 200-series
code. If the certificate is not OK (it's the revoked certificate
of a spammer), it responds with the appropriate error code (554?)
and terminates the TCP connection. 

We'd need to have some sort of plan to deal with servers that
say conventional HELOs - they don't provide a certificate.

There may be a fatal flaw in all of this. I spent less than
5 minutes pondering it. If so, something similar could be
engineered. Note that I'd want to implement the certificate
in the early stages of the SMTP handshake because I'm an
advocate of allowing spammers to steal as little of my
bandwidth as possible. There may be benefits to implementing
it later in the handshake if bandwidth is not important. 


Ed

> --Jason Van Cleve
> 
> 
> On 22 Jun 2003 15:37:37 -0700
> Ed Sawicki <ed at alcpress.com> wrote:
> 
> > On Sun, 2003-06-22 at 15:10, Jason Van Cleve wrote:
> > > On 22 Jun 2003 11:34:56 -0700
> > > Ed Sawicki <ed at alcpress.com> wrote:
> > > 
> > > > One way is to assign certificates to the machines that
> > > > move the mail. Sites that send spam will have their
> > > > certificate revoked. The problem with this is that
> > > 
> > > Isn't that the same as blocking by IP range or domain name, essentially?
> > 
> > It may seem like it but there can be substantial differences.
> > Spammers get one or more blocks of IP addresses from their
> > ISP and move on to other IP addresses as they appear on black
> > lists and RBLs. If a spammer has a /24 block, you have to chase
> > them through 254 addresses, unless you can find out what block
> > they've been allocated and block it all as soon as you discover
> > they're spammers. Unfortunately, many ISPs (like rackspace.com)
> > are not cooperative - they won't tell you the spammer's block.
> > So, you either chase the spammer through his range of addresses
> > or you block all the ISP's addresses (as I've done for rackspace). 
> > 
> > If spammers had to register certificates for their servers
> > with some central authority, and this information was publicly
> > available, we would be able to revoke all their certificates
> > once we discovered they were spammers. It would no longer matter
> > what IP addresses they used or that their ISPs are uncooperative.
> > Other customers (non-spammers) of uncooperative ISPs would not
> > be penalized.
> > 
> > -- 
> > Ed Sawicki <ed at alcpress.com>
> > ALC
> > 
> > 
> > _______________________________________________
> > PLUG mailing list
> > PLUG at lists.pdxlinux.org
> > http://lists.pdxlinux.org/mailman/listinfo/plug
> > 
> 
> _______________________________________________
> PLUG mailing list
> PLUG at lists.pdxlinux.org
> http://lists.pdxlinux.org/mailman/listinfo/plug
-- 
Ed Sawicki <ed at alcpress.com>
ALC