[mail-vet-discuss] -19 of draft-kucherawy-sender-auth-header

Douglas Otis dotis at mail-abuse.org
Wed Jan 14 11:45:36 PST 2009


On Jan 13, 2009, at 9:02 AM, SM wrote:

> Hi Doug,
> At 18:53 12-01-2009, Doug Otis wrote:
>> (see section 3.4.1 of [MAIL]) of an address, the "pvalue" reported  
>> along with results for these mechanisms SHOULD NOT include the  
>> local- part.
>
> "SHOULD NOT" is not an recommendation to do something.

Someone marketing their services using email will read this as saying  
"Unless local-part macros are included within the SPF record,  
annotations will be limited. To be noticed, local-part macros are  
required."  An earlier draft published an example of a local-part  
exploits leveraging cached SPF records.  The exploit is able to  
sustain sizable attacks while utilizing little of the attackers  
resources, beyond the sending of email.  The more a DNS cache is  
inundated, the more effective the attack becomes.  :^(

>> Are you recommending coercion to resolve conflicts?  Not all SMTP
>
> The question I asked was about implementations.  I'm at a lost as to  
> why you see that as recommending coercion.

Since the IP address of the SMTP client is omitted in the  
Authentication-Results header, domains must be assessed on a fairly  
static basis.  Using domains in the case of SPF or Sender-ID increases  
the number of assessments by more than an order of magnitude, that  
will also need to rely on the actions of many additional entities.   
The indirection of domain assessment significantly impairs effective  
responses to PRAs being exploited.  The exploit may have been enabled  
by compromised access, or imprudent record use by some inbound  
provider, neither directly be controlled by the domain.  As recipients  
fall prey, mounting damages will likely have a coercive effect.  Since  
assessment of the SMTP client is precluded by the Authentication- 
Results header, this eliminates practical, prompt, and comprehensive  
assessments, and places recipients at much greater risk.  The omission  
shields providers from being held accountable by pointing to some  
domain, rather than toward the likely source of a problem.  This  
indirection comes at the expense of recipient security.  Too bad  
security and authentication appears to have lost its meaning. :^(

-Doug


More information about the mail-vet-discuss mailing list