Douglas Otis wrote: > By using the local-part in a spam campaign, one cached SPF record > is able to reference an unlimited sequence of MX records. 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. And e-mail providers wishing to offer "per user policies" could also create corresponding subdomains replacing local@xxxxxxxxxxxxxx addresses by say user@xxxxxxxxxxxxxxxxxxxx addresses. Likewise attackers trying to cause havoc can use user@xxxxxxxxxxxxxxxxxxxx addresses, they don't need SPF's local part macro for this purpose. After all in your attack scenario it's the attacker who controls the MX records pointing to bogus addresses in the zone of the victim. > Spammers often send messages continuously. A spam campaign can > come from any source, purport to be from any domain, and yet attack > the same innocent victim which can not be identified by examining > the message. Your attack scenario has nothing to with a spam campaign, the goal of a spam campaign is to send unsolicited mails to receivers. The goal of your attack scenario is to flood a zone with bogus and huge A or AAAA queries. And in your scenario the mail cannot purport to come from any domain, it has to come from domains under the control of the attacker where he manages his bogus MX records. > Compared to an SPF related attack, most auto-replies will consume > a greater amount of an attackers resources, identify the source > of the attack, and not achieve the same level of amplification. Backscatter doesn't consume resources of the spammer (apart from sending the UBE with a forged envelope sender address), and it can be "mail from" any "plausible" address, not identifying the real source. That's precisely the problem solved by SPF FAIL and PASS. > SPF enables a long duration DDoS attack. Sorry, from my POV you still arrive at "MX records can be abused", not limited to SPF (or rather only limited if done using SPF). > Block all SPF records? At least we won't need a new rfc-ignorant zone to implement this proposal... ;-) >> Maybe you should propose some "MX processing limits" for 2821bis. > Most systems are fairly careful about where they send messages to > avoid being blocked, nor would the normal use of MX records require > all targets be resolved. Timeouts recommended by RFC2821 ensure this > operation remains fairly safe, unlike that for SPF. Even the packet > limitation of DNS provides a fairly reasonable limit. I'm not sure that "call back verification" schemes follow the "sending strategy" (4.5.4.1) in RFC 2821, after all they don't send any DATA. You could squeeze quite a lot of names in the reply to an MX query, that's why SPF has an explicit limit 10. SMTP also doesn't specify size limits for MX queries. > 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". Frank _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf