On Nov 3, 2008, at 11:25 PM, SM wrote:
Hi Doug,
At 18:39 03-11-2008, Douglas Otis wrote:
The motivation for this header is in support of a questionable
Sender-ID or SPF path registration scheme. Sender-ID is being sold
as a replacement for source authentication.
The Authentication-Results header was introduced in 2004 as there
wasn't a standardized method to convey the results of DomainKeys
verification.
This header was to bolster the false marketing contentions that Sender-
ID represents an email-address authentication scheme analogous to the
telephone Caller-ID. Unfortunately, it is not reasonable to assume
that authorized outbound SMTP clients will impose restrictions upon
the use of the various and perhaps unintended header fields that may
be involved with the fictional "authentication" method. This is where
the telephone Caller-ID analogy falls apart, and why unintended header
field involvement remains a significant concern, especially for Sender-
ID. Most have learned not to trust email that is not protected with
some form of cryptography. Introducing quack authentication methods
is very likely to only create new victims. There is no exigent
justification for this.
Not having this border header as a substitute for DKIM validation
ensures ISPs will provide access to unmodified messages. To ensure
security, verifying the DKIM signature should be done by the MUA
making the annotation, rather than depending upon an injected third-
party header.
If you go back through the DomainKeys and DKIM archives, you might
find that it was deemed unpractical to expect all MUAs to do DKIM
verification.
The discussion regarding signature time constrains was concluded with
measurements based upon when the message is first received by the
administrative domain, and not when an MUA confirms a DKIM signature.
An x= tag and value imposing tight time constraints does not make MUA
signature verifications impractical. Frankly, accurate "on-behalf-of"
values are far more essential in preventing abuse, than will stringent
signature time constraints provide. Bot-nets are ready working within
extremely short timeframes when compared to that of email delivery.
That doesn't preclude MUAs from doing DKIM verification if they
support it. It can be problematic in cases where the DKIM signature
is time sensitive.
Here again, the Authentication-Results header, in addition to not
including the _IP address of the SMTP client_ when path registration
authorization is used, the header fails to indicate _when_ the message
was received for when DKIM is used.
But of course, it is just email. Getting away with outright lies is
normal. However, most would not expect ISPs to facilitate
authentication deceptions. At least they have deep pockets when they
do. ISPs will have a hard time attempting to blame third-parties that
conform with RFC 5321 whenever their headers result in recipients
being deceived. Nor should Redmond be allowed to demand compliance
with their proprietary scheme.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html