My big accomplishment today–it was an otherwise fairly busy day, still catching up from the last couple of weekends–was adding VERP handling to the AnteSpam daemon process.
Those of you who don’t hang out in email handling circles probably don’t recognize the acronym“1”:#fn1, but if you’re subscribed to a mailing list these days, you’ve probably seen it in action.
What happens is that during the SMTP delivery process, when the mailing list server hands the message to whatever server hosts your mail, it is given a special address as the originator of the mail. This is often, but not always, of the form @bounce-mdorman=tendentious.org@bounce.antespam.com@–the important bit is that the address to which the mail is being delivered is included (albeit mangled) in the address from which the mail seems to be coming.
This might seem weird, but when you send to a non-existent address, any bounce message is almost certainly going to be delivered to that specially encoded address, and modern mail transfer agents make it easy to route all mail for @bounce-*@bounce.antespam.com@ to a program which can then extract the address whose delivery failed and behave appropriately–in the case of mailing lists, by removing the user from the list.
Now you might ask why we would want this–it’s not like we’re running mailing lists, we’re checking for spam.
There’s two reasons.
First and foremost, this will allow us to recognize, in an automated way, that an address doesn’t exist on the destination server, and we can mark that address as non-existent in our database, and refuse to even accept mail for it in the future. This cuts down on the load on our servers and our customers servers.
Second, this means our system will not run afoul of senders who have implemented SPF and customers who pay attention to it. Right now, if a sender has SPF records, and our customer honors them, we will probably not be able to deliver the mail from that sender because when we try and do the delivery we use the original sender address during the SMTP transaction with the customer’s mail server, and we aren’t cleared to send mail for that sender. If we’re using an address that’s in our domain, we are certainly allowed to send it.
Both of these are important quality of implementation issues.
The cool part is that, after an hour of investigation and testing, the actual diff turned out to be a one-line change–we were already using the QMQP protocol to hand clean messages to the postfix system for final delivery (because it operates well over unix sockets, and I was sick of having postfix listening on non-standard TCP/IP sockets for what was ultimately an entirely internal transaction), and it turns out that, because the postfix QMQP service strives to be compatible with qmail’s QMQP service (it was written, I understand, because securityfocus wanted to keep using ezmlm, which depends on QMQP, but wanted to move away from qmail), you just have to use a specially constructed sender address, and postfix will do the hard work for you.
1 “VERP”:http://cr.yp.to/proto/verp.txt stands for ??Variable envelope return paths??, and was pioneered by the qmail MTA, largely for automating bounce handling in its companion Mailing List Manager, ezmlm. Yes, I just wanted to try out the footnoting.
