Murray S. Kucherawy wrote:
[skipping the cleared nits, thanks] About 'iprev':
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.
Okay, buy some asbestos. Wayne added the PTR processing
limit of ten names to SPF because there can be lots of
names, e.g. an IP of a Web hoster.
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?
Version numbers as in MIME-Version: 1.0 or in v=spf1 make
me nervous, nobody's going to upgrade their software just
because a future RFC hopes they'll do. Assuming that A-R
gets traction it will be what you specify now.
Header field names (or FWIW "tags" introducing text in a
TXT or SPF record) are no limited resource, if somebody
really wants an Authentication-Results-Episode-2 header
field in a future RFC let them do it.
I'd be also worried if the <version> offers "them" to
http://en.wikipedia.org/wiki/Embrace%2C_extend_and_extinguish
Authentication-Results "version 1" by a bogus "version 2".
If you keep it anyway one of the two <version> needs a new
name.
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
CFWS can be also a comment, it will confuse naive parsers
implementing what 99.99% of all <procspec> will do, simply
smtp.from or senderid.resent-sender without embedded CFWS.
You use <dot-atom-text> elsewhere, that has no CFWS before
or after its dots. CFWS can contain stuff like NO-WS-CTL,
obs-FWS, quoted-pair, nested comments over several lines.
RFC 2822 says that folding SHOULD be limited to placing
the CRLF at higher-level syntactic breaks. Explicitly
allowing it within <procspec> calls for unnecessary trouble.
Maybe it's only a matter of taste, I'd stay away from it.
value = [CFWS] ( token / addr-spec ) [CFWS]
[...]
<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.
One potential problem, do you need an "empty value" for an
"empty reverse path" or similiar situations ? You don't
have angle brackets for <> if you use <addr-spec> or the
equivalent 2821 <Mailbox>.
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.
Not sure if you have that.
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?
MSAs typically do SMTP AUTH, see RFC 4409 and RFC 5068,
they could wish to note their authentication efforts in
a header field. But I now guess that's not the scenario
you have in mind, you want the border MTA to strip any
old Authentication-Results in section 5 of the draft.
I'm not sure if that's a good idea, "trace header fields"
are meant to stay, aren't they ?
Frank
--
Repost, Cc: to list didn't work for new address