Douglas Otis writes:
> As such, using the terms authenticates and authentication should
> not be used when referring to DKIM or SPF results. Nothing is
> being authenticated.
I'm confused. The sending domain is being authenticated, as well as
as much content as is signed (none for SPF, at least the From and
DKIM-Signature fields for DKIM). Otherwise there's no point to either
protocol. Of course, DKIM does NOT ensure that the use of the Author
Domain is *authorized* (unless the author domain is the signing
domain, it which case it seems reasonable to presume authorization),
but it is *authentic* in the sense of being used as the sending domain
intended.
Or are you referring to the fact that these protocols don't put any
requirements on the security of the DNS?
> The real function is verification of an authorization.
I think you are overcomplicating things here, and I don't understand
why.
We *identify* a terminal of a channel (here by using the IP address
for SPF and the DKIM-Signature for DKIM), then *authenticate* that
identity, and finally accept its communications as *authorized* when
accompanied by an appropriate (secure) token from an "authority". In
many cases the identity is the token (as when a user is authorized to
access a file because she is the owner).
In the case of a domain publishing an SPF "policy", the nature of the
protocol is essentially that "anything from these hosts is authentic
and authorized" (the identity == sending IP is the authorization
token). If you don't want to say that, don't publish any hosts with
your restrictive SPF policy.
Analogously for DKIM, as far as I can see. The signed part of a
message is similarly self-authorizing if the signature is valid, and
if you don't like that, don't sign anything and use some other
protocol. I suppose here you also need DMARC or other policy protocol
to actually announce that you aren't sending any authentic mail with
DKIM signatures.
Agreed, there are good reasons to demand From alignment. This can be
is authenticated by DKIM (assuming the DNS and MTA have not been
subverted), and I suppose SPF (but in a world of virtualization and
shared resources I'm not so sure about SPF).
Again agreed, these don't identify users. But nobody in the mailbox
provider game seems to care about that anyway.
> Section 2,
>
> Was:
>However, there has been
>no single widely accepted or publicly available mechanism to
>communicate domain-specific message authentication policies, or to
>request reporting of authentication and disposition of received mail.
>
> Should be:
>However, there has been
>no single widely accepted or publicly available mechanism to
>communicate domain-specific message verification policies, or to
>request reporting of verification and disposition of received mail.
This is also inaccurate, however. Nothing about the message is
verified by any of these protocols, except the sending domain (and in
the case of DKIM, the integrity of the signed portion of message can
be verified). If you want to be more specific, you could write
"authentication of the sending domain and the signed portion of the
message, if any." (Again, unless you want to question the use of the
DNS as a source of authentication information. But I think that is
outside of the scope of these protocol documents, let alone of the WG.)
> Was:
>As a result, senders who have implemented email authentication have
>had difficulty determining how effective their authentication is, and
>use of authentication failures to filter mail has not been a success
>
> Should be:
>As a result, senders implementing email authorization schemes have
>had difficulty determining how effective their authorization is, and
>use of authorization failures to filter mail has not been a success.
I think this is exactly correct as "was". I think that in the case
where *authentic* communications are *authorized* implicitly, we
should use the weaker term.
> Section 2.2
> Was:
> o authentication of entities other than domains, since DMARC is
> built upon SPF and DKIM which authenticate domains; and
> Should be:
> o authorizations of entities other than domains, since DMARC is
>built upon SPF and DKIM which authorizes domains; and
These and following changes are clearly incorrect, because
"authorization of domains" is done by domain registrars, not by the
domains. Do you mean "authentication" -> "verification" as above? (I
still think this is better as "was", but I'm trying to understand your
intent here.)
Regards,
Steve
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
