In <bc3c01c459ee$82badf70$6e82820a(_at_)mailgatejd> "John Leslie"
<john(_at_)jlc(_dot_)net> writes:
Please understand: for what it sets out to do, one could argue that
SPF _is_ "lightweight". But it sets out to do so much that we cannot
place upper bounds on the processing that might be required.
You can place an upper bound on SPF processing, although I think that
much stricter limits need to be placed in the standards. (Yes, I have
argued with Meng over this subject, I should probably push him again
since it has been over a week. ;-) I have also done DoS attack
studies on SPF, both from the point of view of attacking the receiving
MTA and from the point of view of tricking receiving MTAs into
participating in a DDoS attack on someone else. Obviously I can't say
there aren't any problems, but this is a security issue that I have
certainly investigated.
There's another issue I suppose deserves mention yet again: that
reaching consensus in the MARID WG is just one step towards an IETF
standard. (I'll let others judge how close we are to consensus.)
SPF is (IMHO) absolutely dependent on the use of TXT records in areas
of the DNS tree where other TXT records are likely to be found. We
_know_ we're going to face a lot of flak from DNS experts over this
issue. This cannot fail (IMHO) to slow down the process of becoming
an IETF standard.
I have posted data and analysis of the sizes of SPF records and the
types and sizes of pre-existing TXT records to this list before. I
can give you pointers if you can't find them. (I just posted a short
update using the same subject line, "Some stats on TXT usage in domain
names")
If I could wave a wand and make the problems of using a different RR
disappear, I certainly would. However, from my studies, I can't find
a serious problem with SPF's use of TXT records.
| The two approaches seem complementary to me; is there any reason why
| this WG can't advance both to PS?
I explain in more detail at
http://spf.pobox.com/slides/unified%20spf/
Here, Meng advises folks to not worry about the difference between
HELO and RFC2822. Inevitably, that will lead to a large number of
domains advertising relatively open SPF records, and those relatively
open records being used to "authenticate" HELOs of MTAs which the actual
domain never had the slightest intent of trying to control. And, since
all of this is publicly available in DNS, spammers will quickly compile
a list of these.
I understand your concern, but I think the problem will be
self-correcting. If spammers run out of domains that haven't
published SPF records, and decide that using their own domains is too
much of a problem and therefore start trying to use domains which
aren't tight enough, I think the domain owners will quickly tighten
them down.
As Meng mentioned in another post, there are a couple of ways of
providing per-scope rules, when they are really needed.
But it gets worse: Meng actually advises bypassing further checks
if the HELO passes SPF checking and the domain passes reputation checks.
(Think about it, Meng: I'm sure you'll relent.)
Uh, Hmmm... I'm not Meng, but I have thought about it. I see no
problem with an email receiver being able to whitelist anyone they
want. Whitelists need a verifiable identity, and using SPF to verify
that makes sense to me.
-wayne