Murray,
Both Sender-ID and SPF assume either PRA or MAIL FROM access
restrictions are being imposed by authorized SMTP clients. Since
there are two possible assumptions, it is not safe to consider an
authorized SMTP client provides positive evidence of the source domain
of a message, or for that matter that any restrictions are even being
imposed. Please ignore sales hype that authorization is equivalent to
authentication. It is not. Only the IP address of the SMTP client
will have been weakly authenticated. In addition, the Authentication-
Results header fails to convey which parameter or field explicitly or
implicitly has been indicated as being associated with an SPF record.
Since the Authentication-Results header fails to capture possible
assumptions made by SMTP clients, as well as the IP address of the
SMTP client trusted to make these assumptions, all recipients of
domains authorizing SMTP clients, where incorrect assumptions may also
be made by unknown third-parties, are at risk due to the lack of
essential information being conveyed in the Authentication-Results
headers . By not including the IP address of the SMTP client, the
Authentication-Results header prevents any practical means in which to
mitigate incorrect assumptions or access related problems.
The issue of the Authentication-Results header omitting the IP address
of the SMTP lacks reasonable justification, nor is such omission the
fault of either Sender-ID or SPF. This is an issue specific to the
Authentication-Results draft. One purpose of this header was to allow
MUAs a means to annotate messages based upon the IP address results
seen at the border. To resolve reputation about this IP address, in
addition to that of the authorizing domain, this information must be
contained within the Authentication-Results header.
This seems to have become a religious issue where it is sacrilegious
to question acceptance decisions made by administrators of SMTP
clients. As such, the authentication-results header are not to
capture what reputations may have been checked by the administrators,
and even whether such checks may have timed out, or what assumptions
administrators may have made, especially which SMTP client is being
trusted. Clearly, the MUA must not dare to question decisions made by
the SMTP client administrator deity. After all, allowing reputation
services to note that an SMTP client does not appear to support PRA
evaluations, or that it appears to have been compromised represents
blasphemy. Even where it does not offer a practical solution, the
authorizing domain must be blamed for all errors and compromises, even
when errors are being made by third-parties that have no relationship
to that of the authorizing domain. :^(
Since it is normally going to be the MUA making the annotations, it
remains important that the MUA be provided the information required to
be compliant with section 4.1. Don't expect that all SMTP client are
perfect. No reputation check supporting Sender-ID or SPF would be
complete without checking the reputation of the SMTP client, in
addition to that of the domain. For that check, the IP address seen
at the border is absolutely essential. Please consider that there are
many assumptions being made with respect to Sender-ID and SPF.
Knowing the IP address of the SMTP client would permit tracking
typical errors and server compromises. How else would this be
possible and what possible justification is there not to offer this
information?
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html