[mail-vet-discuss] Authentication vs. Authorization
dotis at mail-abuse.org
Thu Oct 30 12:03:59 PDT 2008
On Oct 30, 2008, at 4:29 AM, Charles Lindsey wrote:
> On Fri, 24 Oct 2008 17:10:14 +0100, Murray S. Kucherawy <msk at sendmail.com
>> An issue has been raised regarding the name of the proposed header
>> field. Some of the methods supported by the draft are specifically
>> message authorization and not authentication (e.g. SPF, Sender-ID)
>> there's a concern that this might mislead some consumers of the
>> field's contents. Do others concur, or is it not something about
>> to be concerned?
> Having read all of this discussion, I conclude that "Authentication"
> actually the *correct* term for what this header does.
> "Authentication" is a statement of assurance about some particular
> of the provenance of a message.
> "This is an authentic Ebay message"
> "It is authenticated that this message came from an Ebay IP address"
> "It is authenticated that this message passed through X during
> "It is authenticated that such and such a header was added by X"
You appear to be an example as to why this header is misleading. A
message received from an "authorized" SMTP client DOES NOT MEAN the
message originated from the domain that listed the SMTP client in
their SPF or Sender-ID "authorizations". In other words, it makes NO
assertion regarding the provenance of the message!
These authorizations are commonly applied to SMTP clients shared by
thousands of other domains. It is not reasonable to assume that an
outbound server restricts the use of PRA in all messages that they
relay, nor it it reasonable to assume that no bad-actors have access
to shared servers. It is fairly common to find non-trivial amounts of
abusive email emanate from virtually any large provider. Any
assertion of "authentication" of an email-address in the case of there
only being an SMTP client authorization would be highly negligent and
would expose recipients to significant risk!
AUTHENTICATION-RESULTS: my-trusted-isp.com; sender-id=pass header.from=jon-doe at e-commerce-are-us.com
This offers no indication what IP address or domain handled the
message. This simply indicates in a very dangerous manner that the
domain "e-commerce-are-us.com" authorized some IP address (which
should have been included in the header) to relay the message.
A much less deceptive header would be:
Border-check-results: my-trusted-isp.com; sender-id=MTA-AUTHORIZED ip-
addr=192.168.200.100 pra=header.from<jon-doe at e-commerce-are-us.com>
> All these are saying different things about the provenance of the
> message. The only thing they have in common is that the statement
> being made has been verified by some technical means.
The results are not always about authentication however by limiting
the method assertion to only being PASS, the typical person, such as
yourself, can be dangerously mislead.
> None of them says *anything* about "authorization" (though that may
> be implied by secondary information available from elsewhere, such
> as ADSP records).
Wrong. Although this draft erroneously describes SPF and Sender-ID as
"authentication" mechanisms, the definition of "pass" indicates that
only the SMTP client has been "authorized". An authorized SMTP
client MUST NOT be assumed to be an assertion as to the origin of a
Perhaps this header should be called "exclusion-results" since it
would be a safer assertion to indicate that a non-authorized SMTP
client appears to exclude this message as being from where it
purports. Unfortunately, an authorized SMTP client does not verify
that an email-address originates from where it purports.
>> Perhaps we could take advantage of a lexical coincidence and rename
>> it to "Auth-Results", specifying in the draft that it covers both
>> authentication results and authorization results. Would that work?
> No, because that introduced "Author" into the possible
> (mis-)interpretations :-(.
Why not border-check-results? The concern about an misinterpretation
regarding authentication should be equally of concern. Do not
overstate what the "technical" method provides.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the mail-vet-discuss