This is about securing the transmission path. Authentication is only
incidental
to that. And in any case, the only identity that's "authenticated" here is
that
of the receiving server, and that's supposed to end up in the Received:
field
the server adds anyway.
I'm afraid I really don't see the point.
For one thing, the fact that the client took the trouble to deal with
authenticating the MX should probably increase the worthiness of the
message.
Not when you have to take the client's word for it.
However, DNSSEC and TLSA lookups, as well as RFC 6125
validation are carried out by the client alone. The server has no way
to know it. In particular, it won't be able to highlight the client's
quality in the Received: field.
And that's exactly the point. I see no case where it makes sense for the client
to insert this field into a message as it is being relayed.
Unless I'm missing something, the only places where that info is going
to be relevant is if the server rejects the message, if positive DSN
was requested but the server doesn't support it, and if the sending
fails because some of the specified checks failed.
Now you're talking about a very different situation. In this case it is
completely inappropriate to insert a field (any field) into the returned
content part of the DSN. It was never part of the message that the client was
submitting/relaying, and that's what is supposed to go there.
That said, this information does make sense to include in the structured return
result part of the DSN - it is in fact an elaboration on the existing
Reporting-MTA field, in that it tells you how you got to the point of talking
to that MTA.
But this is not what Authentication-Results fields are for. Again, this is not
an authentication operation per se. You really need to define a new field for
this information. How-I-Got-To-The-Reporting-MTA is probably unacceptable -;),
so it needs to be something more like Reporting-MTA-Authorization.
I also see no reason why this should be restricted to this particular proposal.
DANE is one way of making sure you're talking to the right server, but it is
hardly the only one. DNSSEC plus traditional certificate hierarchy
authorization also falls into this class, and so do things like using a
IPSEC-secured link, or for that matter a physically secured link. If we're
going to define such a field it needs to cover more ground than DANE.
In those cases,
the client can prepare a bounce where the authentication results are
reported in detail. For rejection, for example, the author might
consume such info and be able to attribute some value to the reason
why the message was rejected, based on the knowledge that it was
indeed done by a server entitled to do so.
They're not really authentication results, but yes, a mechanism to report
this would be handy in some cases.
The real question is whether or not this should be in this document. Since such
a mechanism really needs to be more general, I'm inclined to say no.
Normally, the work done for securing the transmission path is not
noticeable. Some more visibility, in return for the trouble, would
seem to be in order.
I agree, but the question is where to make it visible and in what form.
I think the proposal to make it visible in DSNs has merit, but again,
it's a more general thing than the current document.
Ned