[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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