[mail-vet-discuss] Draft as of 9/4/2007

[Eric Allman]

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