On Oct 16, 2007, at 5:00 AM, Frank Ellermann wrote:
Douglas Otis wrote:
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.
Requiring MX for discovery eliminates additional transactions needed
to assert no policy record or valid email domain. However, the SPF
or RMX concept is seriously flawed.
Defining valid sources might scale when done "by-name" but never "by-
address". By-Name is how MX records declare destinations. PTR
record-sets adjacent to an MX record could associate valid client
domains. Perhaps special names like "_NONE" or "_ANY" could be
defined for PTRs under a _MX-OUT leaf. DNS would then be able to
return addresses needed to validate a specific client host-name
within a single transaction, but not for all possible host-names.
Being able to validate clients within an authorized source domain
should safely satisfy your need for a protection mechanism.
Fully resolving just one MX record for either IPv4 and IPv6 addresses
might necessitate 20 DNS transactions when permitting 10 MX targets.
SPF allows 10 MX records, where each may contain 10 targets. Unless
IPv6 is excluded, subsequent transactions for both A and AAAA records
might be needed where a high level of NXDOMAINs would be ignored.
This means 10 x (10 + 10) or 200 DNS transactions satisfy SPF
semantics for each email-address checked. However, some suggest
using SPF to authorize DKIM domains or PRAs first. When DKIM or PRAs
are not authorized, it is common to then check MAIL FROM. Each
message might therefore invoke 400 DNS transactions per message.
Even after allowing this number of transactions, the resulting list
may not encompass the addresses of all valid outbound hosts.
Use of MX records are normally predicated upon the sending of
messages.
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.
See above.
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 unusable.
See above.
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.
See above.
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.
SPF enables a cached record to redirect the subsequent DNS
transactions of a recipient. In addition, SPF provides an attacker
the means to manage a sequence of MX records independently from what
is seen as the originator.
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.
Logs of the DNS and mail servers may provide clues about which
domains appear to have staged the attack, but the domain visible to a
mail server is able to transition rapidly which prevents any filter
from curtailing an ongoing attack.
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.
Finding one of perhaps hundreds of DNS servers used by an attacker
will not offer a meaningful defence. The ability to redirect DNS
transactions afforded a cached SPF record ensures an attacker can
escape any blocking effort.
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 this?
The recipient decides. They may follow RFC2308 recommendations which
is the lesser of either the SOA MINIMUM field or the SOA TTL.
However some experience problems and truncate the duration. Here is
a common tip given to Windows users:
"By default these negative entries are cached for 5 mins. But we can
tweak the registry to NOT store negative entries at all!"
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.
How long will these records remain? A single cached SPF record can
do untold damage with its ability to redirect recipient
transactions. Rapidly changing these records will not consume much
of an attackers resources. Attackers are extremely adept at fast-
fluxing DNS. It is not 2004 any more.
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.
Why do you think there is a difference between a zombie and a name
server? Why shouldn't a spammer offer an attacking service when it
will not impact their spamming service?
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.
RFC3464 removes incentives which affords greater protection at much
smaller costs. SPF is not the only tool available!
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.
Despite intentions, SPF creates a far graver danger.
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 ?
Regardless, it should not happen more than the number of targets
contained within a single MX record. This attack would also incur
the message and MX record overhead. While a concern, it is not in
the same league.
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.
The same could have been said about the use of DDT as a pesticide.
This attitude will likely require banning SPF before its use can be
irradiated. : (
-Doug
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf