SM wrote:
If this memo replaces the Received-SPF header, then it changes the
requirements on an existing protocol.
SPF is an experimental protocol. Thus, I'm not sure this is a big
deal. Anyone else want to weigh in?
For tracing and debugging purposes, the authentication identifier
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.
I'm not sure I see much of a semantic difference there. Anyone else
want to weigh in?
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.
Again, I'm not sure I see much of a semantic difference there. It's
pretty clear from reading the entire document that the only acceptable
ptypes are those in the registry.
8.3. Other Protocols
[...]
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.
Removed.
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.
Done.
_______________________________________________
NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html