Wandering Thoughts archives

2011-08-11

Friendly 'noreply' email addresses

In yet another installment of me writing things aimed at people who will never read them, I have some opinions on 'noreply' email addresses. I have these opinions because, of course, our mail system has its usual modest pile of email attempting to be delivered to some of those noreply addresses.

(My real opinion is that you shouldn't use any sort of noreply address at all. For a start, it's a terrible user experience. And apart from that, handling bounces is part of responsible mailing practices.)

Here is the thing about noreply addresses: they don't work. People reply to them. Sometimes they are real people; sometimes they are automated systems (such as vacation messages) that are acting on behalf of people. Either way other people's systems are going to try to deliver email to your noreply address, and these delivery attempts are not 'wrong' just because you sent out email from 'noreply@' or put various headers on the original message.

(If you really wanted no replies, you would have sent the email out from the null envelope sender. Of course that sometimes has other side effects, but that's not our problem.)

The unfriendly way to handle your noreply addresses is to make such email sit around endlessly on other people's mail systems. You can do this in one of two ways; your mail system can 4xx such messages, or the domain of your noreply address can be something that more or less exists but doesn't respond to SMTP. The friendly way to handle noreply addresses is the reverse of this, to make your noreply address either bounce immediately or be delivered but go to /dev/null.

(I have no opinion on which option is friendlier, because they are both bad. But then so are noreply addresses.)

Either option is quite easy to implement, and neither will particularly consume much of your resources even with lots of delivery attempts. Modern mailers on modern hardware are quite efficient, especially if they are rejecting everything, and if you have extremely special needs it's not particularly difficult to create a custom single-process asynchronous SMTP listener that just 5xx's all RCPT TOs. If a properly set up noreply-handling mail environment moves the load meter on even a small virtual machine, you are dealing with a major amount of incoming traffic to your noreply address's domain. Perhaps you should look into why that's happening.

FriendlyNoreplies written at 01:25:18; Add Comment

2011-08-02

How to make yourself look bad: broken bounce addresses

We get a certain amount of email with envelope sender addresses that look like your typical modern mailing list software's bounce management handling. They have what looks like individualized addresses and often have 'bounce' in either the local user part or the domain (such as an email message from 'bounce.global.expediamail.com').

I don't particularly look at sender addresses of email to our users. I know about these messages and addresses because some of our users autoreply to these messages, and those replies just sit there on our mail server until delivery attempts time out after a while.

(I do look at our mail queues from time to time, including at the destination addresses of email that seems to be stalled.)

You can guess how good this makes these places look, or more to the point not look. Sending out email that simply fakes all of the signs of a good, well-managed mailing list is an old spammer trick, and this is awfully close to it. At a minimum this shows a significant lack of care in the implementation of these places' mailing list management systems, which isn't likely to make people feel more comfortable with their other mailing list practices. (After all, if they're slipshod with one aspect they're probably slipshod with others, like who they add to their lists and how easy it is to actually unsubscribe.)

Of course I know that this is optimistic. At least some of these places are likely merely going through the motions on responsible mailing list management with no actual substance behind it; in fact, their business model or marketing approaches may actively prevent it. This is a great way to really irritate a certain amount of people but that doesn't seem to matter to these companies (either morally or practically).

(I don't know if this is an active decision to break or not implement accepting incoming bounce messages, or just an accident where the people responsible haven't particularly noticed. Of course there is zero point in spending time to try to tell places such as expedia.com or nvidia.com that some of their email system is broken. If they actually cared they would already know; why they don't care is at best of academic interest. There is little functional difference between incompetence and evil to people outside these companies.)

BrokenBounceAddresses written at 00:05:37; 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.