Re: A new SMTP "3821" [Re: FTC stuff...........]

On Fri, 3 Dec 2004, David Woodhouse wrote:

> On Fri, 2004-12-03 at 09:30 +0000, Chris Haynes wrote:
> > The ones which appear to me to have been added by PRA (derived from Caller-ID)
> > in Sender-ID are:
> > 
> > 1) Abuser can forge addresses at domain
> 
> This is common to PRA and SPF. Anyone with an account on one of the
> 'authorised' boxes (or subnets, if dynamic IP is in play) can sand mail
> which passes. There isn't even an option to require that the mail comes
> from a port < 1024, which is odd.

Agree with all except the "port < 1024" part. Back in the old days, when
computers were significant resources, this was probably implied a person
(eg system admin with root) responsible for a valuable asset. But today it
can be assumed that "port < 1024" does not imply anything.

> > 11) Makes forgery blowback problem _much_ worse
> 
> Not sure about this one. I don't actually see why this is the case.

"Blowback" is the bounces that you get when a spammer forges your address 
as the From: address. Much of the spam run will be delivered, but what 
isn't, will be bounced.

ISP customer Spammer posts mail to that ISP's relay with a forged return 
address. The recipients reject the message due to SPF. Now the relay sends 
a bounce to the "from: address".   This message is from the Relay, which 
will be valid.  So now instead of a a few bounced messages, you get a 
bounce for every message blocked.

Of course, if the target is harrassment, the spammer can just exchange the 
to: address and the from: address and use some ISPs relay.  You can't 
block the ISP's relay without affecting the rest of the email.

This is no difference than a reverse synflood DDOS attack using a
wellknown router.  Syns are sent to your upstream router, with your IP
address as the source. The router responds with a SYN ack. This can easily
be made to saturate a customer link.  The customer can't block the
upstream router.

> > 12) Patent issues
> > 13) spam-profiteering / charges for SPF services
> 
> I don't understand this one either, but I don't think it's specific to
> PRA. 

Patent issues item refers to the patents that apply to SPF and Sender-ID. 
Several organziations said they won't deploy anything that is patented.

Spam-profiteering was tangentially discussed. Basically, an ISP such as
AOL or MSN can charge fees or prevent altogether the unbunding of IP
access and email services.

> > And ones which probably represent universal engineering concerns:
> > 
> > 2) Abuser can use stolen credential
> > 5) Ongoing Maintenance issues
> > 6) Migration issues
> > 9) Lack of universal compliance.
> > 
> > although of course the way and degree to which these concerns mainifest depends
> > on the exact scheme in question.
> 
> In particular, number nine does vary to a vast degree; so much so that
> it should be considered a separate problem for some of them. There's a
> big difference between a scheme which requires _universal_ compliance,
> and a scheme which requires only the sending and receiving parties to
> participate, without any need for the rest of the world to change.

Right. Except that there is typically 3 or more parties to email: The
sender, the relay operator, the mailbox operator, and the recipient.

Secondly, if only a subset of the net deploys SPF, one cannot block mail
based on the lack of an SPF record.  And one cannot simply perform less
testing if an SPF record exists since that would encourage spammers to use
SPF-using ISPs (and in fact, it was found that most of the early deployers
of SPF were spammers). One can only do blocking if SPF deployment is
universal, and that is unlikely.

It is not the case that SPF can be deployed merely with respect to the 
sender and recipient.  There was significant discussion on this point with 
Alan Dekok.

		--Dean


-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net         faster, more reliable, better service
617 344 9000