Around the internet world, specifically dealing with email and MTAs, there are people who are familiar with and have expertise with a number of MTAs. Things like Exchange, Postfix, Sendmail, Qmail, Exim, and so forth. I am not one of those people. So, in writing this series I have learned a few things about the other MTAs.
I said in my previous post not to accept mail (and close the SMTP conversation), try to deliver it and then bounce it back to the "sender." This is bad. <South Park> But you see, I learned something today. Qmail is an MTA that does this by default.</South Park>
Qmail is a mail transfer agent that runs on Unix. It was written by Daniel J. Bernstein as a more secure replacement for the popular Sendmail program. When first published, qmail was the first mail transport agent that was written with security in mind. Other MTAs with security concerns addressed have been written since then.
Qmail is designed to accept mail for all of its domains and not perform any recipient validation. If the recipient doesn't exist, it generates an NDR. In other words, it accepts... then bounces. Off the top of my head, I don't know why Qmail does this by default (a colleague explained it to me but I forget) but it's likely a security feature. My guess is that by not doing any recipient validation in the SMTP conversation, a sender cannot do a dictionary attack against a domain to harvest legitimate email addresses. The problem, of course, is that this can generate backscatter.
Another thing about qmail, and I don't know if this is unique to a particular organization or is the default implementation, is that sometimes it doesn't put in the following header in a bounce:
Content-Type: multipart/report; report-type=delivery-status;
I know that there are some instances of qmail that don't because recently I had to investigate a customer complaint. They claimed that because the bounce message did not have that header (which is required by the Pirates Code), the message was not backscatter; rather, it was a spammer spoofing backscatter and getting through the filters. While it's certainly possible that a spammer would do this, as it turned out it was a qmail-generated bounce message that did not include the header. I then launched into a qmail investigation and learned a bunch about this MTA. They do put this in the bounce message, however:
Hi. This is the qmail-send program at mail.someorganization.com.
I'm afraid I wasn't able to deliver your message to the following addresses.
This is a permanent error; I've given up. Sorry it didn't work out.
So, quite interesting, is that some qmail implementations do not include the Content-Type header but do include the above bounce message. It's not quite complying with the RFC, I mean Pirates Code, but it's partway there.
The moral of the story is this: if you are running qmail, don't just use the default implementation. There are some patches out there (Richard Lyons' BOUNCEQUEUE patch and John Simpson's patches: qmail validrcptto.cdb Patch) that will fix the accept, then bounce behavior.
PingBack from http://blog.a-foton.ru/2008/07/the-problem-of-backscatter-part-13-an-idiosyncrasy/
The two major MTAs (in deployment) that don't send RFC 3464 formatted bounce messages are Qmail and Exim,
Qmail bounces can be detected by the following
Received: (qmail 9999 invoked for bounce);
(where 9999 is an integer that represents the process pid used, and a date follows the semi-colon)
Exim bounces can be detected by the existence of a specific header name
They should add in the line: "It's not you, its me"