Murray,
While not including local-parts will help ensure the Authentication-
Results header itself is less deceptive, this does not prevent use of
Authentication-Results header to annotate PRA or the MAIL FROM email-
addresses. Unfortunately, annotations applied by MUAs will encourage
confidence artist to gain access to the authorized SMTP clients. Weak
security will result in systems being compromised on an ongoing basis,
as is currently the case. When providers are contacted regarding
security issues, their response might be slow or never seen.
When access to an SMTP client has become compromised, there is no
Reverse Authorization Directory that lists the potentially thousands
of domains being put at risk. Even if there were such a list, the
time needed to discover and contact the affected domains, and for them
to then inform theirs DNS providers of required changes, will be
further delayed by TTLs of SPF records. When dealing with fast moving
bad actors who start and finish their deeds within brief periods, the
speed in which reputation information is conveyed represents a vital
aspect of any effective mitigation effort. There are IP address
reputation services that are able to respond within a few hundred
seconds of a problem being detected through automation. This would be
well ahead of most MUAs.
A response based upon a domain name can not be done within a timely
manner, if at all. Blocking at the domain would be highly disruptive,
and would prevent further communications that might indicate the
nature of the new threat. The only salient, timely, and effective
identifier which can establish a transient negative result regarding
trust would be the IP address of the SMTP client. This would be the
IP address authorized by either RFC 4408 section 2.4 (SPF), or RFC
4406 section 4 (Sender-ID). To ensure the reputation of the SMTP
client IP address can be checked, the SMTP client IP address
authorized by RFC 4408 or RFC 4406 MUST BE captured by the
Authentication-Results header. Nothing else would ensure a means to
obtain the information needed to assess either SPF or Sender-ID
results. This is essential to assess the reputation of the
authenticated IP address of the SMTP client. Nothing else other than
the IP address of the SMTP client will have been authenticated within
SPF or Sender-ID results.
Why should an Authentication-Results header cater to providers who
hope to profit from marketing an allusion of security, rather than
establishing a means for security? Adding the IP address of the SMTP
client allows reputation services a means to indicate which method
appears supported by each SMTP client. In addition to dealing with
security breaches, the reputation service might indicate that an an
SMTP client does not appear to limit use of the Purported Responsible
Address, or the MAIL FROM. These aspects of access and use will play
a significant role in what is safe to annotate, and perhaps how it
gets annotated.
The IP address of the SMTP client represents the _basis_ used for
upstream evaluations of Sender-ID and SPF. Including the IP address
is essential when evaluating a source expected to impose restrictions
upon either the PRA or the MAIL FROM. The IP address is essential,
because not all SMTP clients will impose the same restrictions, and
where access to any SMTP client might become compromised. Treating
SMTP clients only by the authorizing domains is not practical and can
not deal properly with the realities of inconsistent protocol adoption
and fragile security.
The IP address used by either Sender-ID or SPF has been weakly
authenticated by way of the SMTP exchange itself. For either SPF or
Sender-ID, only the IP address of the SMTP client will have been
authenticated. Whether the PRA or MAIL FROM even offered an
authorization is based upon a presumption of the scope being applied,
and the access restrictions imposed. Section 4.1 of the
Authentication-Results Header Field draft states:
,---
An MUA SHOULD NOT reveal these results to end users unless the results
are accompanied by, at a minimum, some associated reputation data
about the authenticated origin identifiers within the message.
'---
For either Sender-ID or SPF, the only authenticated origin identifier
is the SMTP client IP address!!!
Identifying compromised systems or protocol implementations must be
dependent upon the SMTP client IP address, and not that of some
authorizing domain. In other words, restrictions imposed upon MAIL
FROM or the PRA are dependent upon the authenticated origin
identifiers within the message, the SMTP client IP address. When
adding either an SPF or Sender-ID result, it is of paramount
importance for vetting the origination of the message, that the IP
address of the SMTP client be included.
Changing the Authentication-Results header to include the basis of the
SPF or Sender-ID results would help ameliorate potential harm of
uncertain scopes, assumed authentication, or when coping with security
breaches. This concern is not about dead horses, or of information
unrelated to the use of SPF or Sender-ID. The SMTP client IP address
information represents the basis for Sender-ID and SPF
authorization. Ensuring the SMTP client IP address availability is
essential to meet the requirements set forth in section 4.1 of the
Authentication-Results Header Field draft.
Not listing this information borders on negligence.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html