In <427ACF67(_dot_)683(_at_)xyzzy(_dot_)claranet(_dot_)de> Frank Ellermann
<nobody(_at_)xyzzy(_dot_)claranet(_dot_)de> writes:
Julian Mehnle wrote:
# 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.
Right. Besides reality of broken DNS servers and firewalls, this also
encourages publishers to use small records. Things like "SHOULD" tend
to be ignored, but if the publisher sees that the receiver "MAY"
ignore their 23k SPF record, I think they are more likely to
reconsider.
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.
Ok, several things:
1) the differences between this draft and the -00 draft are largely
cosmetic, with the major exception of the removal of zone cuts.
The fact that I let things site for several months doesn't change
this. Actually, it means that if you haven't bothered to make
comments about the -00 draft weeks ago, you really don't have much
right to complain about me releasing the -01 draft quickly.
2) As I mentioned in my announcment of these -01preXX drafts, my
intention is to submit it to the IETF, and then solicit another
round of comments from the IETF-related mailing lists. A pseudo
Last Call, so to speak. This isn't your absolute last chance to
find problems, but I do want to make sure that we have our ducks in
a row before we ask less interested folks to plow through the 50
pages of I-D.
-------------- 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.
===
I have noted that you have requested the SPF council to vote on this.
I'll make sure it gets on the agenda.
| 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.
note: in -01pre4, this last sentence was changed to:
In order to prevent the circumvention
of SPF records, rejecting e-mail from invalid domains should be
considered.
This recommendation to reject invalid domains was suggested by the
folks on the IETF namedroppers list as part of the remove of zone
cuts. One of the things that zone cuts allowed is a way for domain
owners to have some say in the use of non-existent subdomains of thier
domain.
Yes, this is reciever policy, but we make other recommendations about
receiver policies when they have ramifications on the sender policy.
For example, we say that Neutral MUST be treated the same as None.
===
| 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.
I'm pretty sure we have just discussed this point elsewhere. I am
very reluctant to change wording that was developed and "blessed" by
the high priests of DNS during the MARID processes.
===
| 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 ?
Already changed.
===
| toplabel = ALPHA / ALPHA *[ alphanum / "-" ] alphanum
That's rather convoluted, and is it correct ? How about this:
toplabel = ALPHA [ *( alphanum / "-" ) alphanum ]
===
The "toplabel" definition was snarfed directly from any of the
following RFCs: rfc1738 rfc2224 rfc2396 rfc2543 rfc2609
rfc2838 rfc3261 rfc3508. These RFCs define things like URLs and SIP.
I think it would be best to keep the definitions consistent.
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.
I know of no way of abusing the timeout. In fact, I know that John
Levine has created test SPF records that can cause problems if there
isn't a timeout.
-wayne