Q: What happens when people don't use qmail?

Silly girl, when will you learn to use qmail?

Today, I get a forwarded e-mail message from my boss. Its text is a normal delivery failure, which means that my mail server tried to send a message to someone somewhere out on this pale blue dot we call Earth and it couldn't. Naturally, I'm supposed to investigate why it happened.

Nobody seems to understand this fact: I use qmail.

<testimonial>
Using qmail means that when a mail delivery fails, it's not my fault. Using qmail means that whenever my mail server encounters something unusual, it does the Right Thing. It correctly identifies the network hiccups from the Great Big Blunders and either defers the message to try again later or immediately tells the sender that there was a fatal error. Using qmail means I never have to apologize to my users for losing or misdirecting their mail. Using qmail means that I have the smug sense of self-confidence to instantly rule out my mail server as a potential source of problems. It's never my fault. It's never a problem with qmail. Because it's qmail, I know that somebody else screwed up.
</testimonial>

Now that you're abundantly aware of the fact that I am utterly unresponsible in the Case of The E-Mail That Couldn't Get Out of the Building, it's time to introduce the other players.

"Jack": Jack is the intended recipient of the e-mail message. He's none too bright, since in a conference call between him, my boss, and me, he clearly and correctly enunciated exactly what the basis of the problem was as was told to him by a more technical person. Then he proceeded to tell an off-the-cuff anecdote about how he couldn't understand that people had trouble sending mail to him "even if they just clicked 'Reply!'" Apparently, Jack thinks that if someone can send a message to you, you must be able to send a message right back to them. Jack, meet the international community of unsolicited commercial e-mail senders. ICUCES, meet Jack. He's a little slow.

"Camille": Camille is the sysadmin at The Place Where They're Not Using qmail. I pity her, since it takes a lot of frustration to (mis)manage something that isn't qmail. Camille has called me throughout the day to try to puzzle this out. "Send me a message," she says. I do. It bounces. She makes a change. "Send it to me again." I do. It still bounces. Same error. Camille isn't a bad girl to talk to, but she's clearly over her head when it comes to mail server administration. Proof of this lies in the fact that she asked me if turning off the "VRFY" feature might have had any significance. Poor thing. She also gets points off for leaving me a message and giving her phone number out of rhythm. It's "five five five, one two seven, eight nine, eight nine." It's not "fivefivefiveone two seven, eightnineeightnine." Lordy.

Now, the crux of the matter is that the remote site uses a broken method of spam detection and control: it does a reverse IP lookup on every connection and if it fails, it refuses the connection. A reverse IP lookup is a rather lame way to test for spam, since the only thing it does correctly is block zombie bots owned by ignorant-type home users who don't know they're sending mail. Problem is, there are lots of legitimate home users who do know they're sending mail, because they are intentionally running their own mail server, but their ISP won't give them the necessary PTR record to make a reverse IP lookup work. Plenty of other businesses and organizations also have never bothered to make their ISP provide a PTR record. PTR record = successful reverse IP lookup. It's not hard to do. In fact, getting through the guaranteed horrendous customer service department of your ISP is much harder than actually implementing the PTR record itself. The reason why so many people don't have PTR records for their mail servers is because it's so much hassle to get anything done at your ISP, and oh yeah, they aren't required to send and receive mail.

Having a PTR record is a nice thing to have, sure, but it's not needed. It isn't a standard, it's an option. And some people don't even have the option; they just plain can't get one. And this remote site is rejecting all of their mail because of it. Some spam filter, huh?

So messages from my mail server are getting bounced because the remote site isn't getting a successful reverse IP lookup first. I must need a PTR record, don't I? That's what Jack says. Jack's not so bright, but that's what the technical folks tell him, so that's what he tells me, at length, and quite thoroughly, too. I wouldn't hold it against him except for the fact that he didn't bother to gauge anything about me first, like the fact that I already knew exactly what he was talking about. So Jack's telling me how to "solve" my "problem", like it's my fault, like it's something I need to fix.

I'd have referred him to the fact I use qmail, but it would have been lost on him. I already have a PTR record (qmail usage notwithstanding). Reverse IP lookups against my mail server work just fuckin' fine, thank you very much. So even though that's why the connection is being denied, it doesn't explain why the lookups are failing in the first place. At this point, it should be obvious to even the most dimwitted individual who holds a photographic understanding of RFC 821 and 822 that it's not my problem: the remote site is unnecessarily looking for an optional PTR record (which I've already configured just so I can avoid having this conversation over and over again with every half-wit domain owner who leaps before they look), and then denying the connection anyway because their MTA software is horribly unnecessarily broken.

With as much trouble as it's causing them, I might stand to make a case for qmail with them.

A: People die.