Re: Spamming...

On Mon, Apr 25, 2005 at 11:01:38AM -0700, James Couzens wrote:
> If you have the time, give SES a look at: http://ses.codeshare.ca 

I looked. SES seems to go for a high complexity route, with lots of
different validation options; I guess it's a reasonable as a way of trying
to please everyone. For example, I don't like the idea of a UDP-based
validation server, since UDP source addresses are easily spoofed, but I'm
not forced to implement it for my own server.

There are competing schemes: SRS, BATV.

However, you have to remember a few things.

* All these things (and SPF too) only attempt to validate the
envelope-sender.

* The envelope-sender has only one purpose in SMTP, and that's to give a
return address for bounces and DSNs. It does not purport to be anything
else.

* The envelope-sender for a given message may be empty.

* The envelope-sender may be validated, but that information is almost never
shown to the end-user; at best it will be put in a hidden Return-Path:<...>
header.

* The From: header may legitimately be different from that, and so may the
Reply-To: header, so even having a validated return path doesn't tell you
anything about the validity of the visible portions of the mail. In that
regard, DomainKeys is attacking the right problem and SES the wrong problem.

So SES doesn't solve the problems of forgery (phishing). However it *does*
solve one quite important problem with SMTP: the problem of joe-jobs.

If you use SES, then you can discard bounces to mails you didn't send.
That's definitely a good reason for implementing it. You will also be able
to safely discard spams which were sent with an empty envelope sender, thus
forcing spammers to put *something* in there.

> I also wanted to respond to the "spammers just buy lots of domains" 
> argument.  Whilst in a black and white argument, you are right, people can 
> just buy more, if you expand the argument to encompass the overwhelming 
> adoption of email as a communicative medium by the entire world, a 
> "globally deployed" SPF could have strong value. 
> 
> Hear me out of course.. RHBL (Right Hand BL's) could be implemented.  
> RHBL's only work if domain names can't be spoofed.  But of course there is 
> the delay in time between a domain name getting picked up as a new spamming 
> domain and it getting into an RHBL.

That to me sounds like an admission that SPF is useless as a spam-prevention
tool, which I believe is definitely true.

Blacklisting spam senders by IP address is likely to be far more efficient,
and we have that already (without using SPF).

> Just my $0.02, not intending to start a pointless debate about SPF, please 
> I know that SPF is not worth talking about, its all been hashed out, I just 
> wanted to interject the point about RHBL's. 

I don't see how RHBL helps, for the reasons you gave. The IP address range
that a spammer sends from is much harder to forge, and much harder to get
new ones.

> I'm also not looking to start a discussion about SES specifically, but more 
> so I wanted to see what was thought of this technique to prevent forgeries 
> and if it has any relevence to IM2000. 

SES involves making some sort of callback to the originator to see if the
inbound message did in fact come from you. That bears some parallels to the
IM2000 model. However, unless it is made impossible to unglue an SES address
from one message and glue it to another, it won't be as strong as calling
back for the actual message *contents*

SES could do this if the cookie involved a hash of the message body, but
SMTP has many problems with making a canonical message hash which survives
the various mutations that messages tend to suffer when going through SMTP
relays.

Regards,

Brian.