Julian Mehnle wrote:
AFAIK he also gave it to you, Frank
I've read -01pre2, my review was later (2005-03-11)
for reasons of transparency, I am publishing here in
its original form, see the attachment
Looking into it I see some stuff discussed only now, like
HELO invalid
# Do not allow SPF to be applied to non-existent domains.
That's IMHO irrelevant, non-existing domains just have no
sender policy, you wouldn't do a -q=any before a -q=spf to
check the existence of a domain separately.
# By _whom_ may oversized records be ignored? By SPF clients?
# Or by DNS servers, too??
AFAIK also irrelevant, it could be a port 53 firewall. The
point is that you MAY ignore it, all details as you see fit.
I'm not telling this to blame Wayne, but just to explain
what happened. Please leave Wayne alone, will ya? *g*
No, I really don't think that "leave Wayne alone" is the best
strategy to get this beast through the IETF standards process.
And I also don't think that less than one week of this public
review is good eough to find all nits. At this moment I have
not yet read anything below line 631 (excl. the References)
in -01pre5.
For info I add some of my now old -01pre2 comments below, bye.
-------------- these comments are now OLD -------------------
Many MTAs not only will still accept source routes in the MAIL FROM,
they MUST accept them as per RfC 2821 and STD 10. They should not
more use them in bounce messages, that's why we need SPF to fix this.
Proposed new text:
Care must be taken to correctly extract the <domain> from the
<sender> as MTAs must still accept source routes (see [RFC2821]
appendix C). Source routes and the %-hack (see [RFC1123]) have
been maliciously used to bypass security systems.
===
| It is RECOMMENDED that SPF clients check not only the "MAIL FROM"
Good idea, note the change from MAY to RECOMMENDED in a document
history (to be removed by the RfC-editor).
===
| While invalid, malformed, or non-existent domains cause SPF checks to
| return "none" because no SPF record can be found, it has long been
| the policy of many MTAs to reject email from such domains. It is
| RECOMMENDED that email from invalid domains be rejected, in order to
| prevent the circumvention of SPF records.
Remove the second sentence (RECOMMENDED), that's a case for a receiver
policy framework. There's nothing wrong with an unnamed Web-cam in
trouble using its IP in a HELO [127.0.0.10] as long as this really is
its IP. And while RfC 2821 declares HELO tv or HELO localhost to be
"malformed" (missing dot) at least host tv is a valid FQDN, and its
potential problems with many receivers have nothing to do with SPF.
It could even have a valid sender policy.
===
| An SPF compliant check SHOULD try to look up and use a record of the
| SPF type first, before falling back to the TXT type. However, the
| client MAY also perform lookup of both types in parallel. If for a
| domain both types are obtained but their contents do not match, the
| SPF client SHOULD return a "PermError" result.
Now you're getting carried away with your "validating implementations".
If both types are obtained only the SPF RR should be evaluated. What
if the TXT incarnation is a short vague policy due to length limits
for the q=txt reply, and the SPF incarnation is a more verbose long
version ? Maybe the SPF has an exp= which doesn't fit into the TXT.
The old solution "SHOULD be identical" combined with "MUST use the
SPF record if both are obtained" was more flexible and clearer.
===
| Unrecognized modifiers SHOULD be ignored no matter where in a record,
| nor how often.
s/SHOULD/MUST/ or what else could be done in this case ?
===
| toplabel = ALPHA / ALPHA *[ alphanum / "-" ] alphanum
That's rather convoluted, and is it correct ? How about this:
toplabel = ALPHA [ *( alphanum / "-" ) alphanum ]
===
Please get rid of the overall optional timeout, it's an
unnecessary implementation detail. Doug Otis already found
a weird way to abuse it in his quest against SPF.
Bye, Frank