Hi Murray,
At 09:52 08-10-2008, Murray S. Kucherawy wrote:
More formal IETF review of draft-kucherawy-sender-auth-header has begun.
Please reference RFC 5322 for [MAIL].
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.
One of the purposes of this draft is to convey the results of various
message authentication checks being applied. Adding
auto-configuration would require changes to existing MUAs. If that's
a requirement, then it would better to devise other mechanisms or
adopt existing sender-to-recipient authentication mechanisms which
are path agnostic. I won't suggest such a requirement because of
deployment constraints.
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
This requires a SMTP extension.
b) digital signing of the Authentication-Results: header, e.g. with DKIM
Do we need another Authentication-Results: header to convey the
results of the verification then? :-)
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.
That's a simple and effective way to determine whether the
Authentication-Results: header should be trusted or not. It works
along the same lines as common practice where we trust the last
Received: header.
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.
Auto-configuration would require changes to POP3 (if that is being
used). Although there is a POP3 extension mechanism, that has not be
used up to now to provide functionality users seek as it requires
changes to the POP3 server and the MUA. Any auto-configuration
proposal would face the same hurdles. This proposal was a simple
one. Adding a mechanism for MTA/MUA trust makes it more complex
without a proportional benefit.
Regards,
-sm
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html