Frank Ellermann wrote:
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.
Added.
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.
Added smtp.helo.
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.
Removed smtp.ehlo, and modified the value to cover both the HELO and the
EHLO case.
Third nit, please update RFC 2554 (now 4954). What you have
as [IANA-HEADERS] RFC 2434 should be RFC 3864 and normative.
Fixed.
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.
OK, I'll look into this stuff.
In section 2.2 you forgot the terminating CRLF for <header>.
Added.
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>).
I don't follow. There can't be later versions of the
Authentication-Results: header specification that might require some
means of disambiguation?
The idea to allow [CFWS] before and after "." in the
<propspec> is outright horrible, please get rid of it.
Why is it horrible? Spaces and wrapping have no semantic importance so
you could crush the entire decommented header down by removing all
whitespace of any kind and still be able to use the value of the header
field.
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.
<addr-spec> is what I'm looking for there. I can switch to that one. I
don't see any productions that I don't want in that case.
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.
Section 4.1 already says it SHOULD be treated as a trace header field.
Example 3: Should spf=pass smtp(_dot_)mail=sender(_at_)example(_dot_)com
actually be spf=pass smtp(_dot_)from=sender(_at_)example(_dot_)com ? 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.
Why would the MSA add that for outbound mail?