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 > received? 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 > 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. > 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. > 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 this ? > 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. Frank _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf