Douglas Otis wrote:
In theory IANA could publish one _spf.arpa "v=spf1 mx a aaaa -all"
record, and everybody could use it with "v=spf1 redirect=_spf.arpa".
That one SPF record can (kind of) reference an unlimited number of
MX records doesn't depend on SPF's local-part macro.
This adds perhaps 21 useless DNS transactions for each email
No, a "v=spf1 redirect=_sp.arpa" would add precisely one transaction
in comparison with directly stating "v=spf1 mx a aaaa -all". Don't
worry about it, it was only a theoretical example.
The SPF policy for xyzzy.claranet.de uses this technique, admittedly
unnecessary in this case. Lame apology, the massive abuse of xyzzy-
addresses in 2004 forced me to check out SPF before I understood the
fine print (here: avoid unnecessary DNS queries). It's not really
"my" policy, otherwise I'd get rid of the (in this case) unnecessary
DNS transaction for the "redirect=" step.
Do you expect everyone to use inbound servers to send?
No. Of course I'd expect that mail to <postmaster> to the IP of an
MTA talking to an MX I care about works. BTW, it would be nice if
only the MXs of the envelope sender address talk to other MXs, we
could then scrap SPF in this "inherent RMX" parallel universe. Just
decree that everybody has an implicit "v=spf1 mx a aaaa -all" policy,
what a dream. Actually SPF is a clumsy approximation of this dream.
Use of MX records are normally predicated upon the sending of
Yes, I proposed a simplification of your DNS attack scenario based
on "call back verification" instead of SPF. AFAIK "CBV" works by
connecting to an MX of the alleged sender, and trying a RCPT TO the
envelope sender address. If that results in "unknown mailbox" the
receiver knows that the envelope sender address is dubious at best.
Spammers also know this, that's why they forge "plausible" addresses.
An SPF FAIL cuts them off at this stage. As long as there are more
than enough unprotected "plausible" (= surviving CBV) addresses the
spammers can carry on as is.
However, overall amplification is much less when a message triggers
an automated response.
When I got about 1,000 bogus bounces and other auto-replies per day
in 2004 I didn't care about other side effects, my mailbox was almost
An automated response is likely to be filtered
Filtering behind a POP3 modem connection is tricky, after all I still
wanted to get "good" bounces, challenges, and other auto-replies.
Filtering or rejecting auto-responses before final delivery needs
something in the direction of BATV plus good heuristics to identify
"non-standard" backscatter (as outlined in RFC 3834).
BATV doesn't directly fight forgeries, it only stops backscatter
before final delivery (ideally rejecting it at the MX of the alleged
originator). It's a nice scheme, use it if you can. But it won't
help me (as receiver) to reject forged "mail from" Douglas Otis.
SPF permits an enormous amount of DNS traffic to be directed toward
an innocent, uninvolved domain.
Well, I'd try something more direct when I'd wish to attack a domain,
your idea is IMO far too convoluted. And your claim that a domain
under attack by bogus A or AAAA queries caused by MX records of the
attacker, based on CBV, SPF, or what else, has no chance to find out
who the attcker is, might be also wrong. The querying hosts can find
out why they do this, and at that point one or more name servers of
the attacker (where he manages the bogus MX records) are also known.
Once the attack duration exceeds a recipient's negative caching, no
additional resources of the attacker are consumed
BTW, who determines the TTL of NXDOMAIN, can a zone under attack tune
Even the attacking MX record might be unrelated to any domain found
within the message.
They're referenced by mx-mechanisms in the SPF policy of the envelope
sender, i.e. the attacker. And this SPF policy record still exists
at least in the DNS cache of the receivers. FWIW, the querying hosts
can find out what's going on.
Expect spammers to take advantage of this generous SPF gift.
Don't confuse "spammers" and "attackers". This might be the same
persons, but the roles are very different. Spammers in their role
as spammer might wish to attack successful anti-spammers, but they
have no reason to prefer your attack strategy based on SPF where
they'd be forced to risk one of their own name servers. I think
all attackers prefer to risk more anonymous resources like zombies.
RFC3464 represents a far better solution as it removes incentives.
No, that's not true. When my addresses were abused it was the
number of bogus DSNs and other auto-replies that bothered me most,
not the size of the DSNs.
And the incentive isn't to send spam indirectly in the form of a
DSN to the forged envelope sender, the incentive is to abuse an
unprotected "plausible" address. SPF FAIL offers the protection.
Call back verification is not part of RFC2821?
True, but I was talking about abusing CBV for an MX attack instead
of SPF's mx-mechanism, and you then hinted that normal RFC 2821
sending strategies won't query for addresses of all names found in
the MX records at once. Actually I don't know what real MTAs do
if they get NXDOMAIN, do they wait before they try the next name ?
DKIM can be processed prior to acceptance
Yes, but unlike SPF not before DATA. I skip the "anti-phishing"
discussion because it's not directly related to "backscatter".
Other solutions are able to prevent the DATA phase for spam. : )
Whatever it might be, it didn't work for me back in 2004. Victims
of backscatter can't wait for worldwide adoption of MTAMARK, CSV,
or "other solutions", they need something working now. SPF works
as designed because it's in the best interest of spammers to stay
away from FAIL-protected addresses.
Ietf mailing list