More formal IETF review of draft-kucherawy-sender-auth-header has begun.
So far the only issue brought back to me is the following:
I'd like to have some consensus discussion around ways to verify that an
MTA supports this draft. You mentioned alternatives including digital
signatures and interrogating the MTA, but dismissed those alternatives.
It's a really important question and one the IESG will latch onto!
It's a question of detecting forged signatures, yes, but it's also a
question of supporting auto-configuration -- the current draft makes
email configuration harder, and it's hard enough already.
The proposals the current draft suggests, which are listed briefly in
Security Considerations, include:
a) interrogating the previous MTA to determine if it's participating in
this specification such that dangerous Authentication-Results: headers are
being removed; and
b) digital signing of the Authentication-Results: header, e.g. with DKIM
The spec doesn't actually mandate either of these. It sounds like the
IESG would likely want one or the other.
My argument against requiring (a) is that this would touch a great deal
more software, actually requiring MTAs to have some mechanism by which
they can be interrogated to see if the MTA itself or a plugin it's using
implement this specification. We could create an ESMTP extension which
announces that the MTA has implemented the spec, but for an MUA to check
it would require an ESMTP session consisting of (connect)/EHLO/QUIT which,
at least for our MTA, would cause a ton of additional logging to take
place. (I realize that, by itself, isn't a reason not to do it, but it
might impact others as well.)
My argument against requiring (b) is that this entire proposal is an
attempt to ensure that MUAs don't have to do all of the authentication
work since the border MTAs have done that for them. Moreover, MUAs are
very likely not in a position to be able to evaluate any of the IP-based
authentication schemes. However, I wouldn't be too opposed to adding text
which says the message SHOULD be DKIM-signed after Authentication-Results:
is added as this limits imposition on MUAs such that they only have to
learn one message authentication method, and there are already
well-defined free solutions to that out there.
A coworker also suggested the following: If you trust that your MTAs from
the border inbound are compliant, then you can pretty much guarantee that
Authentication-Results: will appear immediately above (or perhaps
immediately below) a matching Received: header, and thus you could decide
to trust only those which (a) have such an adjacency, and (b) are from a
host you trust.
Since auto-configuration was brought up, I'm left wondering which of these
requires the least amount of thought and adjustment by sysadmins. It
seems to me all of them require that an MUA know or be able to determine
which MTAs it trusts, so that can't be eliminated. Or can it? Apart from
that though, the complexity of all of those solutions in terms of
configuration seem to be the same to me.
Opinions welcome. Solicited, in fact, since this is all about consensus.
:)
-MSK
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html