[Top] [All Lists]

Re: Last Call: draft-klensin-rfc2821bis: Permitted and prohibited characters in addresses

2008-01-08 15:32:52

On Jan 8, 2008, at 1:38 AM, Frank Ellermann wrote:

Quoting Section 3.6.2.:
 "This specification does not deal with the verification of return
  paths for use in delivery notifications.  Recent work, such as that
  on SPF [42] and DKIM [43] [44], has been done to provide ways to
  ascertain that an address is valid or belongs to the person who
  actually sent the message."

DKIM doesn't look at return paths, it's a kind of "signed timestamp" (Received) from an SMTP POV. DKIM might help to identify mails that should be accepted. By itself DKIM doesn't help to identify mails that should be rejected. SPF FAIL can do, but the deployment of FAIL is not yet so overwhelming to decree victory, see <>

A reference to a dangerous experimental draft is disconcerting. : (

The show 12.6% of domains with name servers publish SPF records. When 4% of those then offer a possibility for FAIL, this represents less than half a percent of domains overall. SPF is not a solution for mitigating MailFrom abuse, nor should SPF even appear to be promoted.

SPF does not consider "no domain" or "no answer" as a criteria for limiting DNS transactions. Both TXT and type 99 SPF records are optional, and SPF does not use different record types to verify IPv6 or IPv4 SMTP client authorizations. Either SPF RRs or address RRs may legitimately return "no answer" when an alternative is being used. When "no answer" is obtained for an SPF record, often an MX mechanism is then automatically substituted. Transactional limits for "no answer" are therefore doubled by the SPF's RR type uncertainty. A purported policy advantage afforded by wildcard SPF records also directly exposes these domains to an SPF macro exploit that might have been otherwise mitigated by a "no answer" limit.

SPF's macros, especially those expanding an email-address local-part, enables a sequence of new and different DNS transactions to be generated by the recipients of spam and based upon cached records from an attacker. An attack that generates a sequence of TXT, type 99, MX, or A, AAAA records may be used to stage a sizeable attack against any other domain, and yet require no additional resources of the attacker. Amplification of the attack, as compared to the spam being sent, can be greater than reflected exploits against open recursive servers. Of course, spam would be sent anyway, making the SPF macro exploit attack virtually free. : (

This SPF macro exploit could use an a infinite number of local-parts to induce recipients into generating an infinite number of new DNS transactions from cached SPF records directed toward any innocent domain. Authorizations for PRA or various DKIM related email- addresses further increases the risks related to SPF macro exploits. Instances for attack span beyond MTAs, where many plug-ins for web- mail and MUAs evaluate SPF authorizations and do not impose even recommended limits. When SPF is used for white-listing, "+all" better ensures delivery and should discourage use of dangerous SPF routines.

I've no real problem with the statement you quoted, I'd only wish that 2821bis offers a better description of the underlying problem: The border MTA is the last place where "ordinary" mails can be rejected without causing harm. "Accept on probation" is a seriously bad idea for "ordinary" mails. "Extraordinary" cases include SPF PASS, where "accept on probation" still works.

A TPA-SSP scheme in conjunction with DKIM could also qualify the validity of a DSN email-address, rather than a dependence upon the IP address path registration. TPA-SSP would also be compatible RFC 1123 5.3.6(a). Either the SPF path registration authorization scheme should be renovated and transformed into a "by-name" process, or it should be dropped as being dangerously unsuitable. : (