On May 26, 2009, at 10:59 PM, Amir Herzberg wrote:
Doug, thanks! I completely agree that applying SPF at the client -
or in fact, anywhere after the border MTA - is probably a very poor
idea, due to the potential exposure to DoS and DNS poisoning
exploits. I just didn't think this people would do it - I'll try to
add warning against it. This is far beyond the question of whether
there is also some real goal in doing SPF validation at this point
(client) [referring to Chris's note].
A warning is likely not something a typical user would know how to
control. SPF record processing is found lurking in many places.
Within AV and various email filtering and annotation schemes that do
not indicate the processing of SPF records will occur.
Unfortunately, some of these schemes are rather poorly written and
even lack some of the recommended albeit generous processing limits.
And I agree that it may be worthwhile also mentioning the 10*10
amplification factor for implementations that allow 10 mechanisms
where each could do 10 MX (or PTR) RR lookups, for a total of 100
DNS queries (or I think actually 111). Notice that again, the use of
SPF by multiple mail agents, e.g. at the client, would provide even
further amplification.
The important aspect of this concern is that SPF _macros_ allow the
SPF record itself to be cached and thereby not expend _any_ additional
resources of the attacker. Macro expansion of cached SPF records by
recipients can generate 10x transactions as a completely free gift to
the attacker! This free attack eliminates a major factor that
discourage most DDoS attacks. This represents an indirect attack that
is difficult to trace, that is likely not logged, and is
substantially free because a final transaction, or even the end of the
SPF record, can result in full authorization regardless of the MTA IP
address.
-Doug
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg