In <427865CA(_dot_)55F9(_at_)xyzzy(_dot_)claranet(_dot_)de> Frank Ellermann
<nobody(_at_)xyzzy(_dot_)claranet(_dot_)de> writes:
Apparently you have _completely_ ignored all points in my
-01pre2 report, I've already found three old issues up to
line 636. See below for this short first part, bye, Frank
I did not ignore all of your suggestions. I didn't apply all of them
either. I think it would be more productive to discuss them here
though, than via private email because I would like other people's
input about what stuff is important, and what isn't.
-01pre5 nits in no particular order:
* Please add a short "document history" with the modifications since
draft -00. Especially list modifications caused by IESG [Discuss]
votes. Add the usual note that this part should be removed by the
RfC editor in the final document - xml2rfc supports this kind of
note, but I've never tested how.
I could easily have missed it, but I haven't found that to be a
requirement. I do try to list the differences in the announcements and
I do provide diffs. It isn't like I'm trying to hide the changes.
* The RfC 2119 key words REQUIRED, SHALL, SHALL NOT, and OPTIONAL are
not used. Probably irrelevant, but Bruce apparently checks this.
Uhmm... I'm guessing this is a joke?
* "Checking other identities against SPF records is NOT RECOMMENDED"
| Checking other identities against the SPF records defined in this
| memo is NOT RECOMMENDED
It's perfectly okay to check the PRA against spf2.0/pra policies,
or a "submitter identity" against spf2.0/submit, etc.
=> Already reported in my -01pre2 nits.
This I-D, as stated in the abstract, deals with SPF version 1
records. I'm not going to touch "spf2.0" records. (Well, I won't
unless the SPF council says I should.)
* "many MTAs will still accept such things as source routes (see [RFC2821]
appendix C), the %-hack (see [RFC1123]) and bang paths (see [RFC1983]).
These archaic features have been maliciously used to bypass security
systems."
They MUST accept source routes, archaic or not, it's a MUST in 2821,
=> already reported in my -01pre2 nits.
There's no special problem with the %-hack from the POV of SPF, the
RHS behind the first unquoted "@" is the domain (or domain literal).
Otherwise explain what you expect in this case.
Here is an example of something I applied form your -01pre2 list. I
changed the %-hack reference to your suggested RFC1123.
As far as the %-hack not making any difference from the point of view
of SPF, I do not believe that is true in all cases.
backbone!cabal%schlitt(_dot_)net(_at_)midwestcs(_dot_)com is inherently
ambiguous about
which "domain" is being dealt with. Different MTAs will respond
differently, often based on configuration options. Where a bounce
would end up is anyone's guess. I think it is worth a short sentence
to make sure that SPF implementors are aware of these kinds of issues.
* 2.5.4 "it should be made clear that text is not trusted."
| it should be made clear who proposed this explanation.
Maybe a bad case of DEnglish, I miss an article for the word "text".
You are right, there should be a "the" before "text". I've changed
this to:
If the information doesn't originate with the checking
software, it should be made clear that the text is
provided by the sender's domain.
Better?
(If you mentioned this in your -01pre2 list, I'm sorry I missed it.)
* "greylisting" where by the MTA can issue an SMTP reply code of 451
My 1977 dictionary still has "whereby" in one word (?)
I think you are right. fixed. thanks.
* client MAY also perform lookup of both types in parallel.
? client MAY also perform a lookup of both types in parallel.
? client MAY also look up both types in parallel.
I think the last suggestion is the best.
* If for a domain both types are obtained but their contents do not
match, the SPF client SHOULD return a "PermError" result.
| match, the SPF client MAY return a "PermError" result.
It could simply pick SPF before TXT and be done with it. I still
think that there can be valid reasons for different records, e.g.
no exp= in the TXT version due to size limits.
=> Already reported in my -01pre2 nits.
The language dealing with the SPF vs TXT DNS RRs was hashed out
between MarkL and (unamed) "DNS gurus". I don't see this as being
worth battling them on it, but I'm also not sure if the "DNS gurus"
will care.
Personally, I don't have strong feelings about this. What do others
think?
-wayne