Murray S. Kucherawy wrote:
Proposed diffs from the -16 draft, based on this discussion so far,
are attached.
Comments?
The changes look good to me.
One question below.
@@ -1427,15 +1483,49 @@
of hostnames whose "Authentication-Results" header fields are
trustworthy; however, this list should initially be empty.
- Proposed alternate solutions to this problem are nascent. Possibly
- the simplest is a digital signature on the header field that can be
- verified by a posted public key. Another would be a means to
- interrogate the MTA that added the header field to see if it is
- actually providing any message authentication services and saw the
- message in question, but this isn't especially palatable. In either
- case, a mechanism needs to exist to verify that the host that appears
- to have added the header field (a) actually did so, and (b) is
- legitimately adding that header field for this delivery.
+ Proposed alternate solutions to this problem are nascent:
+
+ 1. Possibly the simplest is a digital signature protecting the
+ header field, such as using [DKIM], that can be verified by an
+ MUA using by a posted public key. Although one of the main
+ purposes of this memo is to relieve the burden of doing message
+ authentication work at the MUA, this only requires that the MUA
+ learn a single authentication scheme even if a number of them are
+ in use at the border MTA.
+
+ 2. Another would be a means to interrogate the MTA that added the
+ header field to see if it is actually providing any message
+ authentication services and saw the message in question, but this
+ isn't especially palatable given the work required to craft and
+ implement such a scheme.
I am still trying to get my head around this, but I am thinking that
defining a new ESMTP capability for "I provide authentication services
and strip bogus Authentication-Results header fields" would be a half
hour job, so why not do that?
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html