Re: Last Call: draft-klensin-rfc2821bis: Permitted and prohibited chara

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  
> <http://spf-all.com/>
A reference to a dangerous experimental draft is disconcerting. : (

The http://dns.measurement-factory.com/surveys/200710.html 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. : (
-Doug