Wandering Thoughts archives

2016-11-11

My view on accepting bounces and replies to your email

This topic came up in comments on yesterday's entry about Yahoo Groups not accepting bounces of their email, so I'm going to make it an entry and elaborate on my views here.

My views on accepting bounces are pretty simple: if you send out email using anything but the SMTP null sender, you have a responsibility to accept bounces of it back. In fact, not just bounces alone; bounces and replies, because some of the recipients will have out-of-office and other auto-responders (whether implemented on the server or in their IMAP client, and yes I've seen both). Since you have to accept replies and replies may be in arbitrary formats and come from random addresses that are the result of forwarding and other things, in practice you must accept all email to any address that has recently sent out email.

(We can have a rousing debate over whether you 'must' accept email merely to the MAIL FROM of outgoing email or also to the From: or Reply-To: of the email. My pragmatic answer is that there exist systems that will send replies to the latter, so yes, you should.)

By 'accept' I mean merely that your SMTP receiver must accept the message during a SMTP transaction. Technically you may immediately drop the message in /dev/null if you want; your obligation is merely to insure that the mail systems generating bounces and replies are not stuck with either the bounces (as they would be if you don't accept or reject them outright) or bounces-of-replies (as they would be if you rejected replies).

(Throwing bounces away locally is a sign of a spam operation, since you're ignoring delivery failures and will therefor continue grimly trying to email addresses that are simply not working. But that's different from irritating other mail system operators.)

You have no obligation to accept bounces, replies, or even general email from the null sender address to addresses that have not sent email, or that do not send email that will ever leave your domain. In particular, people with sender address verification systems that assume that all addresses will accept email from the null sender are doing it wrong.

(Not that sender address verification is a good idea in general, but there are more worse and less worse ways of implementing it.)

Since modern mailing list systems individualize the MAIL FROM of every outgoing message to every recipient, they have a built in way of knowing what local email addresses have recently sent email and thus should accept it back. Or they can just accept everything if they're going to throw it all away anyways.

When receiving replies I feel that it is legitimate to respect the DMARC policies of the MAIL FROM, even if this causes you to reject some incoming messages. I will wave my hands about rejecting things at SMTP time that are properly identified as spam. In the specific case of mailing list software and VERP, I think you should accept everything since it's just going to automation.

On a purely pragmatic level, I've written before about how not accepting bounces make you look bad and how broken bounce addresses don't fool anyone any more. The pragmatics are pretty clear: if a random new sending domain doesn't accept bounces and (auto-)replies to their email, the odds are very good that they're a spammer. It's not a sure thing, but it is a strong smell and you can expect people to react to it.

(And it's not as if it's particularly difficult or expensive to set up a simple email server that just throws away everything it receives. I even have something that can do this sitting around and I'm pretty sure you could run a high-capacity install of it on the smallest, cheapest instance AWS offers.)

spam/AcceptingBouncesAndRepliesView written at 22:12:23; Add Comment

Yahoo Groups slides further down the spam source slope

I've written about Yahoo Groups' spam problem before and the situation has not gotten any better since 2014. Instead it's gotten worse, as I tweeted:

Yahoo Groups is now refusing to accept bounce messages for their messages, if you had any remaining doubt that it was a spam operation now.

You can pretend to be a legitimate mailing list operation even if you spew tons of spam with individualized MAIL FROM origin addresses (which real mailing list software does too). But this pretense falls apart when your theoretical legitimate mailing list operation stops accepting bounces, because the entire reason to individualize your MAIL FROM addresses is so that you can automatically track bounces of your messages and do sensible mailing list things like automatically remove addresses that don't work any more.

(This particular bounce only exists because for some reason this Yahoo Groups email wasn't scored as spam by our commercial anti-spam system. It was recognized as spam by the place the local recipient forwards their email to, so now we have a bad bounce we have to sit on.)

Of course I'm not so cynical (yet) that I think Yahoo is deliberately turning Groups into a spam operation, or at least I don't think that outside of angry moods when I'm especially grumpy. Instead I expect that it is a combination of two factors. First, Yahoo is just not bothering to spend resources on keeping 'unimportant' bits of Yahoo Groups in operation, and that includes the systems that do or don't accept return bounces. Second, I rather expect that Yahoo has no interest in reducing nominal usage of Yahoo Groups by throwing people off of it. Spammers are probably a very major source of remaining Yahoo Groups volume, which means that throwing them off would cause usage to shrink drastically very fast. That doesn't look good. So Yahoo looks the other way; users are users, right? Never mind what they're sending.

(I believe that Yahoo also attaches ads to every Yahoo Groups email message. More email volume, more ads attached, more revenue coming in, the better that Groups and Yahoo looks, and so on. An aggressive indifference to the consequences of revenue-generating activity is not exactly new, in Yahoo or elsewhere.)

There are parts of Yahoo that I will genuinely miss when the whole thing eventually collapses, like Flickr. But I loath Yahoo Groups with a dull passion these days and will be quite happy to see it die, whenever that comes to pass. Hopefully soon. When it happens, it will be good riddance to bad rubbish.

spam/YahooGroupsSpamII written at 00:08:54; Add Comment


Page tools: See As Normal.
Search:
Login: Password:
Atom Syndication: Recent Pages, Recent Comments.

This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.