Murray, a few comments.
Will there ever be any reason to extend the ABNF for either "result"
or "ptype"? If so, I suggesting adding new "x-result" and/or
"x-ptype" for future extension, with explicit language saying what an
interpreter should do with values that it doesn't understand.
Alternatively, don't add the x-* fields but explicitly say that
interpreters MUST ignore the entire header field if they do not
recognize a value. Or perhaps say that they should ignore that
clause but interpret the rest of the header field if they can. The
point is to define whatever interpretation should be universal in the
face of future extensions.
The name "authres-id" seems to imply to me to be unique across all
space and time (for example, like Message-Id). But it looks like it
is really identifying the authentication service instead of the
authentication results. If so, I suggest changing the name to
"authserv-id" or some similar to avoid confusion.
One small ABNF glitch (at least, maybe):
header = "Authentication−Results:" [CFWS] authres−id
*([CFWS] ";" methodspec propspec )
This does not permit something like:
Authentication-Results: mail.example.com (verification server)
Specifically, if CFWS is present then "; methodspec propspec" MUST be
present. I propose that this be fixed by changing it to:
header = "Authentication−Results:" [CFWS] authres−id
[CFWS] *(";" methodspec propspec [CFWS])
In the definition of token, I suggest importing it from section 5.1
of RFC 2045 rather than Appendix A. I believe 5.1 is the normative
definition; Appendix A is the "collected BNF" and is, I believe,
technically informational.
Tiny glitch: in section 3 you define "border MTA" to be "the first
MTA which is listed as a mail exchanger (MX) for the recipient
domain." This is not the same as the definition in section 1.3, and
is also unclear (at least to me). Does this mean "the lowest
numbered MX"? Then what does it mean if you have several "best"
MXes? What if you had:
example.com IN MX 0 a1.mail.example.com
IN MX 10 b1.mail.example.com
where the intent is that either a1 or b1 works and does the full job,
but b1 is supposed to act purely as a backup? It looks like a1 would
be a border MTA but b1 would not. I think you can fix this by just
deleting the sentence in section 3.
Section 5 says that relaying MTAs SHOULD NOT add an A-R header field,
even if they actually do check the results and take actions on the
basis of the results. That seems like it can create a mystery. I
suggest either changing the text or adding an explanation for this
behavior.
Section 6.2, I suggest naming the registry explicitly. Right now it
is implicitly named "Method Registry", which makes no sense out of
context. For example, it might be called "Email Authentication Method
Name Registry".
That's all I could find today....
eric
_______________________________________________
NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html