[BULK] Re: SORBS contact

Sun Jul 31 18:32:05 UTC 2011

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 at 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 at 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 at 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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20110731/4ec00f82/attachment.sig>