On Dec 12, 2008, at 4:33 PM, Scott Kitterman wrote:
On Fri, 12 Dec 2008 11:47:17 -0800 (PST) "Murray S. Kucherawy"
<msk(_at_)sendmail(_dot_)com> wrote:
What does the group think?
I always considered the purpose of this header is to communicate
authentication results. I don't think an IP address is an
authentication result. I'd think it was out of scope.
Sender-ID or SPF do not authenticate a domain! These schemes indicate
whether a domain within a message _authorized_ the IP address of the
SMTP client.
For Sender-ID or SPF, only the IP address of the SMTP client has been
weakly authenticated by the SMTP exchange. If the IP address of the
SMTP client were in doubt, this would not be diminished by an SPF
authorization.
There are serious unresolved issues with Sender-ID and SPF. One being
an undefined scope of the SPF record as used by either Sender-ID or
SPF. The lack of consensus as to what scope is valid for some SPF
records represents a significant concern. This happens when results
are relayed by Authentication-Results headers without the type of SPF
record and the IP address authorized being accurately noted. Those
that expected their Mail From to only offer authorizations to SMTP
clients, may be surprised to find recipients misapplying Sender-ID
(from their perspective) where a From, Sender, or Resent-* header
email-address is annotated as having been authenticated.
This overreach of authorization into authentication becomes a serious
problem when the authorized SMTP client NEVER assured the Purported
Responsible Address belonged to the account granted access. The
repeated overstatements as to what Sender-ID provides represents a
form of coercion against providers who have not implemented Sender-ID,
but who will then be exposed to negligent handling of the poorly
defined Authentication-Results header.
Bot-nets and compromised systems still plague the Internet. Access to
an SMTP client may become compromised and the SMTP client may have
been authorized by hundreds of different domains. It would be far
less disruptive to assign a negative reputation to the IP address of
the SMTP client, than to assign a negative reputation to all the
authorizing domains. This is especially true when reputation is
retained for a period long enough to allow notification of the problem
sent through different SMTP clients. Notification and correction of a
compromised system is NOT possible when reputation is applied at the
domain. In fact, the disruption would be so sizable as to make a
corrective action impractical.
There is no reason not to include the IP address of the SMTP client
within the SPF or Sender-ID results. Stop describing the
authorization process as "Authentication". Again, for either SPF or
Sender-ID, the only weakly authenticated element would be the IP
address of the SMTP client. The only element that should be in scope
would be the IP address of the SMTP client.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html