On Oct 10, 2007, at 12:12 AM, Frank Ellermann wrote:
Douglas Otis wrote:
Due to the macro nature of SPF, full processing is required for
each name evaluated.
If what you call "full processing" is the procedure to fetch the
policy record of the domain in question, and match the connecting
IP against this policy for a PASS / FAIL / "DUNNO" verdict, then
this doesn't depend on using macros or not in the policy.
IP address evaluations to determine a PASS / FAIL / DUNNO verdict may
require the expansion of macros inserted into SPF records. SPF
macros have the following syntax:
%{symbol | rev-label-seq | # of right-most labels | chars-into “.” }
rev-label-seq = “r”
chars-into “.” = “-” | “+” | “,” | “/” | “_” | “=”
# of right-most labels = 1 - 128
symbol =
s = email-address or EHLO (initial parameter)
l = left-hand side of email-address (initial parameter)
o = right-hand side of email-address (initial parameter)
d = email-address domain or EHLO (initial parameter)
i = SMTP client IP addr decimal octet labels (initial parameter)
p = r-PTR domain with IP addr validated (not initial parameter)
v = "in-addr" IPv4, or "ip6" if IPv6 (auto generated)
h = EHLO host-name (initial parameter)
Macro expansion and text strings can be combined with any SPF record
mechanism and CIDR mask. Any email-address differing in just the
local-part must then be iteratively processed across the SPF record
set (up to 10 follow-on SPF records or mechanisms).
For example, an MX record may be located using a label derived from
some component of the email-address local-part. The address for each
target name within the MX record must then be resolved and perhaps
masked prior to checking for a match. The macro expansion therefore
permits the same SPF record to cause a different set of DNS
transactions to occur over the duration of a spam campaign. The
macro expansion provides the spammer a means to fully leverage
recipient resources any number of times against any domain. The
domain being queried can be wholly unrelated to a domain within the
email being evaluated. In otherwords, a flood of queries generated
by spam recipients can target any innocent bystander. The SPF record
is able to conclude with "+all" and still obtain a PASS while staging
their completely free attack.
Maybe you mean that macros can reduce the chances for a DNS cache
hit, e.g. for per-user-policies based on the local part macro.
The per-user-policy feature of SPF makes a reflected amplification
attack entirely free for the spammer. Each new name evaluated from
their cached records can generate 508 KB in DNS traffic, a higher
amplification than that achieved in an open recursive attack.
The SPF group dismissed this concern by suggesting DNS amplifications
could be further increased by including a series of bogus NS records.
A single message can be sent to 100 different recipients. 100 x 100
= 10,000 DNS transactions! Each message might be evaluated twice,
once for the PRA, and then again for the MAIL FROM. Who knows,
perhaps this might include the DKIM domain if the use of SPF is not
denounced.
With SPF, the recipient might be interested in the PRA, or MAIL FROM.
When I talk about SPF it's generally RFC 4408, i.e. MAIL FROM and
HELO, not the Sender-ID PRA. The PRA doesn't necessarily help to
identify a permitted or forged MAIL FROM. In other words the PRA
or FWIW DKIM are not designed to avoid backscatter.
DKIM could be extended to avoid backscatter and replay abuse.
Unfortunately, Sender-ID is being heavily promoted as the anti-
phishing solution. A problem not addressed by RFC4408.
when an SPF hammer is the only tool
Folks didn't like the idea to reintroduce RFC 821 return routes ;-)
Of course receivers are free to use any tool to avoid backscatter,
but SPF is today the only tool designed for this job.
I do not agree. Discouraging abuse by using RFC3464 is a far safer
tool. SPF is dangerous and breaks email.
Cleaning up how DSNs are constructed would be _far_ more effective
than asking that all DSNs be dropped when SPF does not produce a
PASS.
No. When I was the victim (back in 2004 before SPF started to
work) the _size_ of DSNs and other backscatter wasn't the main
issue, the _number_ of bogus auto replies was the real problem.
SPF now gives bad actors a much more dangerous tool than auto-replies
ever represented. : (
JFTR, "not PASS" can be FAIL or "DUNNO". FAILs should be rejected.
Your idea to abuse DSNs for indirect spam or malware delivery is a
valid consideration, but in practice the volume of all backscatter
not limited to DSNs is the real problem.
Limiting the size of DSNs is okay, but it's not "far more
effective" than "reject a.s.a.p.", in fact it misses the point wrt
backscatter.
This was in terms of reducing risk. SPF is a dangerous mechanism
which attempts to leverage a recipient's resources. Had the
recipient known who sent the message, SPF would not be needed. As a
general rule, when the source is unknown, any scripted use of
resources offered MUST be extremely limited. SPF violates this rule.
Perhaps that is why Bell Canada ensures all addresses achieve a
PASS. : (
Oops, bell.ca still has this ridiculous policy, that certainly
won't help them to reduce backscatter.
Obviously that is not why the SPF record is published. At least the
"+all" discourages use of dangerous SPF libraries while also reducing
the breakage and permitting white-listing.
Auto responders aren't in a good position to verify the validity
of the return path. Good positions to do this are the MSA based
on RFC 4409 and later the MX based on RFC 4408.
RFC4408 did not mitigate a potential DDoS exploit. This exploit
exists when recipients attempt to process SPF as specified.
Actually they've to ignore a SHOULD in the security considerations
of RFC 4408 if they wish to participate in your convoluted attack
scenario. And the SPF RFC did mitigate this potential with several
MUSTs in the security considerations in comparison with pre-MARID
drafts.
No! Although there are many SPF parsing libraries in distribution
that ignore the SHOULDs, the example attack scenario is not prevented
by any RFC4408 SHOULD or MUSTs! The attack was based upon a _fully_
RFC4408 compliant SPF parser!
-Doug
_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
