Re: Authentication-Results: header draft

Murray S. Kucherawy wrote:

> I just sent this off to ietf-822 and MAAWG's "techincal" list.

In your table you limit spf2.0/mfrom to smtp.from.  I think you
also need smtp.helo just as for v=spf1, because RFC 4406 states
that spf2.mfrom is the "mfrom" defined in RFC 4408.

RFC 4408 uses the term "MAIL FROM identity", but it's obviously
the same concept.  For an empty reverse path RFC 4408 constructs
an ersatz-"mfrom" postmaster@<sender> using the "HELO identity"
as <sender>.  Most relevant v=spf1 drafts had "MAY check HELO",
later changed to "SHOULD check HELO", because it's obviously a
good idea to do it anyway when it was always allowed.

I think this means that spf2.0/mfrom and v=spf1 have the same
semantics wrt smtp.helo, receivers SHOULD check HELO / EHLO as
obvious shortcut because they'd check it anyway for an empty
reverse path.  In practice it would be a bad idea to publish
spf2.0/mfrom instead of v=spf1, so it might be irrelevant.

I think you could remove the "smpt.from" line from senderid, or
add smtp.helo just in case, if implementations treat it like
v=spf1.  

Another nit, what's the point of "smtp.helo" vs. "smtp.ehlo"
in your table ?  I think it muddies the waters for MUAs trying
to make sense of it.

Third nit, please update RFC 2554 (now 4954).  What you have
as [IANA-HEADERS] RFC 2434 should be RFC 3864 and normative.

The proposed 'iprev' authentication is apparently the same as
"v=spf1 ptr -all" minus the processing limits for PTR checks
in RFC 4408.  One "IETF certified troll" will whine, you're
in deep shit with this idea.  You should provide a reference
to I-D.ietf-dnsop-reverse-mapping-considerations, and maybe
acknowledge April Lorenzen's prior art "VarA".
  
> Hoping to hand it off to our IETF AD soon

IMO (s)he needs a fair warning about this 'iprev' beast.  I
like it, but better copy some "security considerations" from
RFC 4408 and the reverse mapping I-D.

In section 2.2 you forgot the terminating CRLF for <header>.

IMO <version> for a header field is hopeless, besides you
can't have two different unrelated <version> definitions in
the ABNF.  Just kill the first (used in <header>).  

The idea to allow [CFWS] before and after "." in the
<propspec> is outright horrible, please get rid of it.

The <mailbox> is likely the <Mailbox> in RFC 2821, not the
<mailbox> in RFC 2822, you'd get a parser problem with the
latter.   Maybe you mean 2822 <addr-spec>, in both cases
add the damned [CFWS] before and after the alternative:

  value = [CFWS] ( token / addr-spec ) [CFWS]

Better check which 2822 obs-cenities I've lost by going
from <mailbox> to <addr-spec>, but I think you don't need
<obs-angle-addr> with <obs-route>.  But maybe you need an
empty path, I'm not sure where that is in RFC 2822.

Shouldn't the header field be a *trace* header field ?
I don't see this at the moment in your I-D, please add it
if it's missing.

Example 3:  Should spf=pass [email protected]
actually be spf=pass [email protected] ?  Ditto
in example 4+5.  It's rather odd that the example 4 border
MTA bothers to check spf and sender-id after an auth=pass,
ditto in example 5.  I think you'd better add an example
for auth=pass where that's added by the MSA.
 
 Frank