On Sat, 30 Jul 2011 15:18:17 EDT, William Herrin said:
2. I assume the subscription request came from a web page because if it was from an email request you received then you ignored my SPF records when generating the confirmation request. That was OK in 2001 but in 2011 you ought not be doing that.
So let's see. Certainly, you can try to make the case that SPF tends to help eliminate *some* of the use cases of that one SHOULD in that RFC. However: 1) SPF is not itself a mandatory required service for SMTP. 2) SPF usage is not anywhere near 100%. 3) Last I checked, the SPF grammar still included things like ~all and ?all and people were still using them. Let's look at the actual domain that owns the misbehaving Barracuda that started this thread: absfoc.com. 300 IN TXT "v=spf1 mx ptr a:mail.absfoc.com a:outbound.absmailgateway.net ?all" Hmm.. .'?all'. Remind me what that means Biil, my reading of RFC4408 is obviously wrong, because it seems to say "we explicitly don't claim anything about mail sent from any other addresses". That sort of shoots your "If Woody had gone straight to the SPF record, none of this would have happened" claim. That SPF record doesn't advise that mail arriving from other sources should be viewed with suspicion - it's saying even the mail admin of the domain doesn't want to make a value judgement. 3a) SPF doesn't prevent forgeries. In particular, it doesn't do anything for determining the validity of the left-hand side of the address... The above 3 alone tend to say to any reasonable person that if you're doing something because SPF isn't in place, you need to *keep* doing it *because SPF isn't universally in place in a configuration that's usable for this purpose*. But wait, there's more... 4) SPF doesn't in fact address the issue that using a null <> is dealing with - there are *many* cases where the subscription request can't be delivered even with SPF in place. Consider all the cases where your mail server may emit a 4xx or 5xx response to a mail. Many of those are in response to mail that was generated to once-valid email addresses. 5) And don't bother saying "but we'd reject the mail during the SMTP transaction yadda yadda yadda", because the fact you would do so is in fact the cause of the biggest headache scenario, and the one that many products *USE* that null MAIL FROM for: 5a) We receive a mail from joe@mailboxes-r-us.com requesting a subscription. It's all nice and pretty, and even both DKIM and SPF validated as that user at mailboxes-r-us.com. 5b) We send out the confirm message, and mailboxes-r-us.com accepted the mail because 'joe' is a fully paid up customer in good standing. 5c) Oh, and 'joe' has set forwarding to joe@herrin.us. 5d) That MAIL FROM:<> isn't for your benefit, it's for mailboxes-r-us.com's benefit so they don't have to generate a bounce when your SMTP server informns them that joe@herrin.us isn't a valid address anymore because you enforced your TOS on their spamming butts, or it's not a valid address anymore because they didn't pay their bill, or it's not valid anymore because they *did* pay their bill but your back office people screwed up posting the credit to their account, or their mailbox is full, or they've got a syntax error in their mail filter file, or some *other* user's mail just went totally bat-guano crazy and filled your spool, or... or pretty much *any* case where your mail server will generate a 5xx error in response to a forwarded mail. mailboxes-r-us.com is now the proud owner of a bounced message it didn't originate. And you're upset because some people looked at the SHOULD in the RFC, and thought hard about it, and decided that the administrivia mail in question should have the exact same delivery semantics as a bounce, MDN, or DSN, for exactly the same reasons (allow a mailer to drop it on the floor rather than potentially double-bounce it), and decided that it met the "for good reason" exemption that RFC2119 specifically includes as *the distinguising difference between MUST and SHOULD*. I'll make you a deal - *you* donate the resources needed to fix all 5 of the above Internet-wide(and yes, point 5 means you need to totally ban store-and-forward mail forwarding), and all the *other* corner cases that are involved, and then I'll talk with the people who are violating your sensibilities regarding that SHOULD. And even at that point, that Barracuda is almost certainly *still* broken, because I'm pretty darned sure it doesn't include code that says "reject MAIL FROM:<> unless it's a specifically blessed MDN, DSN, bounce or other RFC-compliant format", it's just got a "reject <> yes/no" switch someplace.