At 16:11 01-11-2007, Murray S. Kucherawy wrote:
1.2. Requirements
This memo establishes no new requirements on existing protocols or
servers, as there is currently no standard place for the described
data to be collected or presented.
If this memo replaces the Received-SPF header, then it changes the
requirements on an existing protocol.
For tracing and debugging purposes, the authentication identifier
Kucherawy Expires May 4, 2008 [Page 8]
Internet-Draft Authentication-Results Header November 2007
SHOULD be the domain name of the MTA performing the authentication
check whose result is being reported.
I suggest changing that to a recommendation as follows:
It is RECOMMENDED that the authentication identifier be the domain
name of the MTA
performing the authentication check to guarantee uniqueness and
for ease of tracing and
debugging.
That allows the implementor to choose an authentication identifier
while providing some guidance.
An MUA MUST ignore any result reported using a "result" or "ptype"
not enumerated by this specification or a later amendment to it.
I suggest using the following text. It covers any later amendment to
the specification.
A MUA MUST ignore any results reported using a "result" not
enumerated in this
specification or "ptype" not in the Email Authentication Method
Name Registry.
8.3. Other Protocols
Mitigation of the forged header attack can also be accomplished by
moving the authentication results data into meta-data associated with
the message. In particular, an [SMTP] extension could be established
which is used to communicate authentication results from the border
MTA to intermediate and delivery MTAs; the latter of these could
arrange to store the authentication results as meta-data retrieved
and rendered along with the message by an [IMAP] client aware of a
similar extension in that protocol. The delivery MTA would be told
to trust data via this extension only from MTAs it trusts, and border
MTAs would not accept data via this extension from any source. There
is no vector in such an arrangement for forgery of authentication
data by an outside agent.
It is the intention of the author to follow this proposal with drafts
proposing the above two extensions.
The last sentence could be a note to be removed at publication time
as it doesn't pertain to this draft.
C.2. Nearly-trivial case; service provided, but no authentication done
A message that was delivered by an MTA that conforms to this standard
but provides no actual message authentication service:
Could you use "conforms to this specification" instead of "conforms
to this standard" in the example cases (C2 and C3)? It's not a standard yet.
Regards,
-sm
_______________________________________________
NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html