Douglas Otis wrote: > 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). Yes, an attacker can use 10 mx mechanisms in his malicious policy for domains under his control with names containing 10 different parts of the LHS (local part) in his envelope sender address. > The SPF record is able to conclude with "+all" and still obtain a > PASS Sure, a PASS for "mail from" unknown strangers only guarantees that bounces and other auto-replies won't hit innocent bystanders. A PASS can be still spam or an attack, but it won't create backscatter, that is more or less the idea of SPF. > A single message can be sent to 100 different recipients. 100 x 100 > = 10,000 DNS transactions! The number of RCPT TO for a given MAIL FROM at the border MTA where SPF is checked is irrelevant, it's evaluated once. Actually the same MAIL FROM at a given border MTA has no further effect while the SPF and MX records of the attacker are still cached. But of course an attacker can send more mails to more domains with different envelope sender addresses, and he can tune the TTL of his SPF and MX records. Whatever he does, your attack scenario depends on the mx mechanism, and you get an amplification factor of about 10 DNS queries to the victim per DNS query to the attacker. The attacker could also try to abuse "call back verification" with his bogus MX records for a better amplification factor without SPF. AFAIK SPF is so far the only protocol specifying "processing limits" for DNS based attacks. RFC 2821 certainly doesn't talk about it, and I'm not aware of any processing limits wrt SRV or NS records. Maybe you should propose some "MX processing limits" for 2821bis. > DKIM could be extended to avoid backscatter and replay abuse. Hardly. DKIM is intentionally independent of SMTP, it doesn't look at the envelope sender address. The envelope sender address (aka return path, mail from, or bounce address) and the MX concept are the essence of SMTP, anything else is syntactical sugar. The PRA is the best approximation of the envelope sender address, but DKIM also doesn't look at the PRA, it's not designed to fight backscatter. > Unfortunately, Sender-ID is being heavily promoted as the anti- > phishing solution. A problem not addressed by RFC4408. RFC 4408 doesn't discuss PRA or phishing or 2822, it's about SMTP and backscatter. For discussions why the best approximation PRA isn't good enough see the <http://www.openspf.org> pages. Using PRA as anti-phishing solution might make sense, with several caveats addressed in the IESG note. Unlike PRA pure DKIM offers no FAIL, it can help to identify various kinds of "non-phishing". That's not the same as "anti-phishing". > Had the recipient known who sent the message, SPF would not be > needed. Indeed, SPF is used to figure out when "originator as indicated in the reverse path" in RFC 2821 is acceptable (PASS) or should be rejected (FAIL) at a border MTA. Other uses of SPF are at best nice to have, and in the worst case dangerous. >> 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. If all they want is a PASS they could use a short "v=spf1 +all" without the other PASSing gibberish they're publishing now. > At least the "+all" discourages use of dangerous SPF libraries No, "v=spf1 +all" and more verbose policies with the same effect are perfectly valid and supported by SPF libraries, dangerous or otherwise. > the example attack scenario is not prevented by any RFC4408 > SHOULD or MUSTs <http://tools.ietf.org/html/rfc4408#section-10.1> | SPF implementations SHOULD limit the total amount of data obtained | from the DNS queries. For example, when DNS over TCP or EDNS0 are | available, there may need to be an explicit limit to how much data | will be accepted to prevent excessive bandwidth usage or memory usage | and DoS attacks. Frank _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf