[mail-vet-discuss] Authentication vs. Authorization
dotis at mail-abuse.org
Mon Oct 27 11:33:40 PDT 2008
On Oct 24, 2008, at 8:03 PM, Tony Hansen wrote:
> Doug, I think I figured out where you took a left turn and came to
> the wrong conclusions about the Authentication-Results header.
> The Authentication-Results header indicates the results of *us*
> proving the authenticity of something in the message.
In the case of Sender-ID, this method only determines whether or not
an SMTP client has been authorized. An authorized SMTP client does
_not_ authenticate the associated email-address, even though the
Authentication-Results header appears to imply that an email-address
is being authenticated. In fact, for most of results included in this
header, _nothing_ is being authenticated. In the case of Sender-ID or
SPF, the IP address associated with the SMTP client is _not_ being
captured in this header, unless a reverse lookup is also being made.
It seems rather doubtful MTAs will be expected to make reverse DNS
assessments due to the high latency caused by DNS timeouts from the
lack of publication or the high number publication errors in the ARPA
> In other words, *we've* authenticated the DKIM and DK signatures,
> and we're communicating *our* authentication results to our MUAs.
Both recipients and those writing MUAs to annotate messages may not
understand what is _not_ being done. After all, this draft describes
all the methods as "authentication". This Authentication-Results
header communicates the method with "pass" and:
"d" and "i" tag with DKIM this is okay
From header field with ADSP-DKIM dangerously misleading
From or Sender field with domainkeys dangerously misleading
ip address of SMTP client with iprev this is okay
PRA with Sender-ID extremely
MAILFROM HELO with SPF dangerously misleading
Even for DKIM the Authentication-Results header can be misleading.
With ADSP-DKIM, the email-address associated with the signature is
_not_ assured to have been authenticated. Compliance with ADSP
currently requires use of an "Author Signature" which specifically
prohibits the signing domain from using an "on-behalf-of" value to
indicate what they authenticate. However, a recipient or the MUA
writer may logically conclude that the email-address was authenticated
when it was not. ADSP could have allowed the "on-behalf-of" to comply
with the DKIM spec, where it then would be safer to note the matching
components of the From header field as having been authenticated.
Using ADSP in conjunction with DKIM in an implied "authentication"
manner clearly goes beyond the DKIM charter. The Authentication-
Results header implies DKIM in conjunction with ADSP is to assert the
identity of the Author! This is especially wrong when compliance to
ADSP, due to the "Author Signature" definition, actually prevents the
signing-domain any means to refute or to prevent the misleading
Authentication-Results header from being added.
|6. Security Considerations
| Security considerations in the ADSP are mostly related to attempts on
| the part of malicious senders to represent themselves as authors for
| whom they are not authorized to send mail, often in an attempt to
| defraud either the recipient or an Alleged Author.
Ironically, the "Author-Signature" definition does not clarify what is
to be done when a signature added by a domain is not "on-behalf-of"
the From header field. Since the ADSP record is domain wide, must
email now only be sent on behalf of the From header field, and never
on behalf of the Sender header field?
Is ADSP, Sender-ID, and a misleading Authentication-Results header a
clever way to create significant liabilities for providers that grant
access based upon the authentication of an entity not reflected in the
DKIM/From or the Sender-ID/PRA? One might note these two schemes can
be applied simultaneously and be in conflict with each other. ADSP,
Sender-ID, and Authentication-Results headers will be placing many
providers at significant risk. It is best not to lie about what is
being authenticated, even when dictated by an ill considered drafts.
> We are *not* communicating whether that original token was an
> authentication or authorization of anything. We are only
> communicating what we've proven. We're providing the results of
> *our* authentication process.
The element verified and that should be included, but may not be,
within a border-check header is:
for ADSP-DKIM or domainkeys is the _validated domain_,
and for SPF or Sender-ID is the _authorized IP address of the SMTP
Including an email-address within a header with such a misleading
label will surely endanger a great many recipients and leave them
prone to confidence artists.
What new term for authentication must be invented when there really is
>> Describing these SPF/Sender-ID results as "authentication" will
>> mean domains publishing SPF records are now in jeopardy of
>> dangerously misleading recipients whenever a shared outbound server
>> is employed somewhere. The risk will become painfully apparent
>> whenever a bad actor's only "authentication" credential is having
>> sent email through one of the authorized SMTP clients. There are
>> _many_ cases where independent domains share a common outbound
>> server. While path registration may help reduce a range of
>> spoofed DSNs, it is NEVER safe to refer to this mechanism as an
>> AUTHENTICATION method. This is not the first time that this
>> concern has been raised. A correction now should be preferred over
>> a change at a much later date. It is shameful to be sloppy about
>> something that will prove _extremely_ misleading.
>> AUTHENTICATION-RESULTS: my-trusted-isp.com; sender-id=pass header.from=jon-doe at e-commerce-are-us.com
>> Someone reading this header added by their trusted ISP will
>> logically come to a horribly wrong conclusion. They are likely to
>> believe that the email-address "jon-doe at e-commerce-are-us.com" had
>> been authenticated. Despite the outrageously misleading header
>> label, the information contained within the header only indicates
>> that the SMTP client had been authorized. An authorized SMTP
>> client must not be misrepresented as providing an assurance of the
>> authenticity of the email-address! Why make it so damn easy for
>> It would be ludicrous to suggest that all domains should not use
>> shared outbound servers, or that all outbound severs should
>> authenticate the use of every email-address within a PRA location.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the mail-vet-discuss