On Dec 15, 2008, at 9:55 AM, Murray S. Kucherawy wrote:
Victor Duchovni wrote:
No, the draft correctly captures the fact that SPF/SID are there to
support (a rather lame IMHO, but still popular mechanism for)
domain reputation. IPs have nothing to do with it. The sending
domain, which has signed for the ISPs/ESPs whitelist either is or
is NOT whitelisted.
I will make no further comments on SPF and IPs, over and out.
+1. To recycle a comment used on me recently: "Is the horse dead
yet?"
This does not put to rest the issue that this header, by its very
name, will give recipients an impression that an email-address has
been authenticated when such an assumption may not be safe. In
addition, when a system becomes compromised, there will be no
practical means in which to mitigate the problem. While static
positive reputations of a domain may work in specific cases, this
approach is not appropriate in general. Unfortunately, the
Authentication-Results header fails to offer an identifier that has
been _authenticated_ as the source of the message, and is instead
insisting only a domain seen as authorizing the IP address of the SMTP
client is only identifier that matters. While providers may not want
the IP address of their servers included in the results header, such
inclusion is _absolutely_ essential when dealing with compromised
systems.
Compromised systems are a reality. This ongoing problem should raise
significant doubt about white-listing a domain, especially when there
is also doubt about whether it had been evaluated by the authorized
SMTP client due to scope uncertainties. It does not somehow become
safe to obscure the SMTP client IP address that is being authorized by
either SPF or Sender-ID. Is should not matter that the lie of domain
authentication has become popular or well marketed. It remains a
dangerous and potentially injurious lie. Including the IP address
would be a way to admit that an uncertain domain will not offer enough
information upon which to evaluate reputations prior to apply
annotations based upon the Authentication-Results header.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html