Re: Trouble with Sender Authentication

On Nov 2, 2006, at 8:12 AM, K.J. Petrie wrote:

> SPF, for instance, breaks forwarding. This will stop it catching on  
> widely, because domain owners are likely to use forwarding for  
> their incoming mail.

Forwarding is a problem in any address-path registration scheme.   
Sender-ID alters rfc2822 by asking for a Resent-From header,  
superseding either Sender or From headers, to be added by forwarding  
agents.  Those advocating SPF-Classic want the MailFrom altered by  
the forwarding agent where the original domain is folded into the  
local-part along with a hash and a time-stamp.  DSNs are relayed  
through the last forwarding agent.

There is an alternative to SPF-Classic that uses DKIM signed  
messages.  An association of the Mail-From domain with that of the  
signing-domain can validate the DSN address through an association  
scheme.

An association could look something like:

<base32(sha1(signing-domain))>._DKIM-M.<mail-from> TXT "d=signing- 
domain"

See:
http://tools.ietf.org/wg/dkim/draft-otis-dkim-dosp-02.txt

This scheme assures the DSN address in one reliable and small DNS  
transaction.  There would not be any concerns related to forwarding  
breaking an address path registration scheme.  An association scheme  
works without the cooperation of forwarding agents as well.

> And where will that leave us?  Back where we started, but with  
> increased network traffic and DNS load doing useless checks.

It is much worse actually.  SPF scripts allow each spam to generate  
hundreds of targeted DNS transactions using the resources of those  
recipients foolish enough to run these scripts.  Poorly conceived  
timeouts in SPF libraries compounds the problem, as this also removes  
congestion avoidance.  SpamAssassin's default timeout is 5 seconds,  
for example.  Any SPF domain can target any other domain with 100 DNS  
transactions per instance, name, and recipient.

See:
http://www.ietf.org/internet-drafts/draft-otis-spf-dos-exploit-01.txt
  or
http://www.sonic.net/~dougotis/maawg/SPF%20Exploit%20Concerns-maawg.pdf


> Certainly, my experience with spam is that, wherever it appears to  
> come from, there are only five or six basic variants being sent  
> repeatedly at any one time. Therefore, it is likely all this mail  
> is coming from only five or six real sources which have managed to  
> infiltrate the Internet at a large number of points. Do we really  
> imagine people who do that will be put off by the need to run a  
> little more automated research?

More than 70% of these messages are introduced from compromised  
systems, often in concert in the tens of thousands.  SPF allows for  
exploits far more nefarious than research.

> Identifying spammers (or, more likely, trojanised mailers) and  
> their reply websites (or, again more likely, trojanised proxies) is  
> only as good as the abuse desks which take action, and  
> overstretched resources take time to close down these gateways. The  
> spammers know this, and presumably make their profit in the  
> intervening interval, and are always ready to move on. They are the  
> Internet's suitcase boys, standing on a street corner and ready to  
> run when a police officer comes within sight. To make spamming and  
> the associated  activities unprofitable requires an automated  
> system which either cannot be abused, or which punishes abuse so  
> rapidly it cannot be worthwhile.

DKIM always signed by the transmitting entity in conjunction with  
standardized opaque identifiers and an opaque-identifier revocation  
scheme would be a solution that could streamline abuse reporting  
aimed at eliminating much of the spam.

See:
http://tools.ietf.org/wg/dkim/draft-otis-dkim-security-concerns-01.txt

This list remains available for continued discussions of any MARID  
related issues. The spf-discuss reflector required participants to  
first agree with the promotion of SPF.  An insurmountable barrier for  
some. : )

A primary use of SPF is for white-listing bulk senders (otherwise  
frequently being block-listed).  DKIM in conjunction with an SMTP  
Client association scheme more reliably fulfills that purpose, where  
the DNS transactions are significantly reduced as well.  When  
validating the EHLO is first, a DDoS attack is rather improbable.

-Doug