Wandering Thoughts archives

The temptation of selective sender address verification

You could say that we have at least three mail problems. We have a requirement to accept all email by default, we have people who either forward all their mail to places with more strict spam policies or have autoreplies, and such people sometimes get email from known domains that can't be sent email (sometimes in annoying ways). The result is a moderate amount of email camped out on our system that I know will never be delivered, and a sender address verification temptation.

There all sorts of reasons why general callback-based sender verification is a bad idea; people much more articulate than I am have written lots about this. I would never do general sender verification. However, the temptation is that I could make our mailer do selective sender verification, verifying only addresses at certain domains. Say, the known domains that send us stuff that then causes bounces or autoreplies that said domains never accept back. This wouldn't make callback verification any less of a bad thing but on the other hand I would only be applying it to domains that are already behaving antisocially towards us (as far as we're concerned). In theory , this would have the net effect of blocking email from those 'bad' domains but (mostly) only to the extent that they themselves are being bad SMTP citizens; if they became willing to accept their email addresses back, we'd become willing to accept their email.

(In theory this is what happens with all uses of callback sender verification.)

Sadly, this is a bad idea and illustrates a certain dangerous mindset that I can get into when I think about spam. Spam fundamentally irritates me; it just gets under my skin and acts as one of my hot buttons. It's uncomfortably easy for me to slip into a mindset where I start losing balance and perspective, one where the most important thing is blocking spam and other concerns are decidedly secondary.

In theory I could argue that we have a defensible technical reason for insisting on callback verification for these domains; after all, our email system effectively chokes on these undeliverable addresses. In practice I know full well that the mail system is not being particularly affected by the current or likely future level of delivery attempts to these domains and that the real reason I want callback sender verification for these domains is that it'll cause us to stop accepting their email. We have no mandate to stop accepting email from domains I don't like (rather the contrary), so I'd be trying to sneak it in through the back door in a vaguely deniable fashion.

(Having written this, I am hopefully now somewhat better prepared to resist this particular temptation. But I have to say that it's very attractive to the bit of me that likes poetic justice and hates spam.)

How to irritate sysadmins and give mailers heartburn with your MXes

Here's a simple way to irritate sysadmins and give mail systems some nice heartburn. First, send some email that will bounce or provoke autoreplies (for example, you could be sending email to an address that forwards it to somewhere that will reject it). Next, have the following set of MXes:

; dig +short mx enviodigital2.info.
0 mail1.enviodigital2.info.
5 mail2.enviodigital2.info.
10 mail3.enviodigital2.info.
15 mail4.enviodigital2.info.
20 mail5.enviodigital2.info.
25 mail6.enviodigital2.info.
30 mail7.enviodigital2.info.
35 mail8.enviodigital2.info.
40 mail9.enviodigital2.info.
45 mail10.enviodigital2.info.
50 mail11.enviodigital2.info.

Now, have your machines configured so that most or all of these MXes do not respond to connection attempts on port 25, and certainly none of them accept your email back (temporary SMTP failure codes are ideal here). If you want real bonus points, have some machines accept SMTP connections but then process everything very, very slowly before timing out.

The net result is that any remote system that is foolish enough to send you bounces or other email will take (for a typical Exim configuration) more than a half an hour to handle one pass of trying to deliver a single message back to you. Almost any MTA will try each MX in sequence and each MX will occupy it for multiple minutes before it times out; with 11 MXes this adds up fast. This is a great way to give all sorts of MTAs various amounts of heartburn; how much heartburn depends on how they handle their queues. Sadly, Exim is particularly bad at this because it handles all email in a single queue instead of sorting things into one queue per target domain.

(This sort of thing leads me to a vaguely evil temptation with callout sender verification, but that's another entry.)