ietf
[Top] [All Lists]

Update of draft-otis-ipv6-email-authent

2013-05-09 20:52:58
Dear ietf, spfbis, and repute,

Until an identifier is linked with the source of an exchange by way of 
authentication, it must not be trusted as offering valid reputation input. For 
example, a valid DKIM signature lacks important context.  A valid DKIM 
signature does not depend upon actual sources or intended recipients, both of 
which are essential elements in determining unsolicited messages or even 
whether the message is valid.  SPF only offers authorization of Non-Delivery 
Notifications, and can not be considered to represent actual sources.

Three different authors attempted to repair DKIM's header field issue within 
the WG process but repairs were rejected.  As with the DKIM WG, being right 
about likely outcomes will not always prevail in offering safe and dependable 
protocols offering a well understood services.

The initial intent for DKIM was to help prevent spoofing, but that effort ran 
astray with desires to extend DKIM beyond its capabilities.  Flexibility 
allowing DKIM to be relayed removes typical rate limitations protecting a 
domain's reputation from occasional lapses or from messages easily taken out of 
context.

Since a valid DKIM signature may not preclude prepended header fields, this 
raises important questions.  When such spoofing does occur, which domain's 
reputation should be affected?  A domain too big to block that does not add the 
non-existent header field hack? A domain being spoofed to improve statistical 
filtering?  It is clear those actually responsible for abusive exchange may be 
ignored by these strategies.

Better solutions at enforcing security and offering fair reputations are 
readily available.

http://tools.ietf.org/html/draft-otis-ipv6-email-authent-01

DKIM can not be used to establish reputation without a link with those 
responsible for its transmission.  Neither DKIM nor SPF established those 
actually responsible for the exchange.  Today, unfortunately, the only thing 
that can be "trusted" in email is the ip address of the host connecting to the 
mail server - and even that can be subverted with BGP injection.

Regards,
Douglas Otis
<Prev in Thread] Current Thread [Next in Thread>
  • Update of draft-otis-ipv6-email-authent, Douglas Otis <=