In <20040818215247(_dot_)GE50011(_at_)verdi> John Leslie
<john(_at_)jlc(_dot_)net> writes:
I recognize how hard it is to put together a spec: in no way do I
wish to belittle the work that went into this. But RFCs are forever.
(Please be assured I was at least this picayune with Dave and Doug's
drafts.)
Thanks for the review John! I hope many of your points make it into a
new draft.
] 2.1.8 Minor Version
] This document only specifies records with a minor version of "0".
] All published records MUST start with "spf2.0/pra".
]
] Future versions of this document may define other minor versions to
] be used.
This leaves me confused as to how we could manage a transition to
the next minor version. I recommend giving careful thought to that
expandability issue.
The creation of a minor version number was mandated during the IETF-60
session. No semantics of what the minor version number should do were
given. I've talked with both Mark and Meng about this, and we all
agree that we can't think of any use for a minor version, which was
why it wasn't there in the first place.
] 4.2 "include"
There's a lot of room for confusion between "include" and "redirect".
If one looks long enough, it becomes clear that the basic difference
is that "include" returns, thus can generate only four conditions,
while "redirect" doesn't return, thus can generate all seven.
I think it would help to say so in as many words.
I'm not sure what you mean by "four conditions", but I don't think
your understanding is correct. An include: can cause both PermError
and TempError, and if there is a match, it can generate any of Pass,
Fail, SoftFail and Neutral.
Personally, I think that "include" is a really bad name for this
mechanism. I think a much better name would be something like
"if-pass". I've seen a lot of people get tripped up by thinking that
the include mechanism effectively includes another record, which it
doesn't. Since we are going to have to republish everything anyway,
it would be possible to rename the the include mechanism without
causing any problems.
] 4.3 "a"
Here we get into serious IPv4 vs. IPv6 territory.
I assume that if <ip> is v4, one implements an "A" lookup, while
if <ip> is v6, one implements an "AAAA" lookup. It wouldn't hurt, IMHO,
to say so explicitly.
Up in section 4., there is the following text:
When any mechanisms fetches host addresses to compare with <ip>, when
<ip> is an IPv4 address, A records are fetched, when <ip> is an IPv6
address, AAAA records are fetched.
I tend to agree that this should be made more explicit
] 6.1 Unrecognized Mechanisms and Modifiers
] New mechanisms can only be introduced by new versions of this
] document.
While I _can_ wrap my mind about the idea that we have a <ver-minor>
field which MUST always be ignored,
Yeah, I guess if someone can come up with a very clear purpose for the
minor version, I think it will just be a forever-wart caused people
who happened to go to the IETF-60 session and didn't really think
things through.
[...], I'm having trouble wrapping my
mind around the idea that we MAY introduce new mechanisms, but all
receivers that haven't been updated yet MUST fail to evaluate our
SPF2 records in a useful way.
The whole "unknown mechanism" logic in for SPF and SenderID is totally
bogus. There is *nothing* that can be done with unknown mechanisms
that can't be better done with unknown modifiers. Worse, they cause
confusion and allow for typos to cause sporadic failures.
For example, if someone publishes "spf2.0/pra mx ipv4:1.2.3.4 -all"
they will never get to the -all. If most of the valid email comes
from the MX IP addresses, this error will not show up most of the time.
This is actually a very common error in SPF records. The result of
this "unknown mechanism" stuff is that SenderID will be less reliable,
with zero upside.
] 6.2 Processing Limits
]...
] MTAs or other processors MAY also impose a limit on the maximum
] amount of elapsed time to evaluate check_host().
I have to admit that I'm very disappointed that these processing
limits have not been improved. Right now the only way a SenderID
implementation can prevent DoS attacks against third parties is to not
be RFC compliant.
The DoS problem isn't with the domain owner generating records that
require too many DNS lookups on their server. Domain owners will
quickly figure out that that is a bad idea.
The DoS problem isn't with the receiver of the email. If SenderID
checking is too expensive, they will simply become non-RFC complaint
and abort the checks.
The problem is that a malicious domain owner can set up SenderID
records that cause traffic to a third party victim. Then, by using
some simple SMTP sessions, the malicious can greatly amplify their
bandwidth by generating bogus DNS request and use the receiving MTA to
hide who is actually doing the attacks. The load created on each
individual receiving MTA can easily be made low enough that they will
not notice that they are being used as part of an attack.
-wayne