For a couple of years now, one of the easiest, yet very powerful anti-spam techniques is sender verification. Often spam is sent from bogus email addresses which contain random strings and are therefor also hard to blacklist. In this process the receiving mail server simply checks the `From:` header of every mail and asks the sending mail server if it actually knows the sending user. If not, the receiving mail server will most likely immediately discard the message with a “550: sender verify failed”. To not put a high load on the sending server, the result is cached in the receiving one, so if you receive 20 mails from bob@foo.com, its sending server is probably only asked once (or not at all if it has been asked before).
My exim instance has sender verification enabled by default and I like it, because ~90% of the spam doesn’t even need to get scanned by spamassassin, which in return means lower server load. However, sender verification also makes problems sometimes, especially if automatically crafted emails from, lets call them “legacy”, systems should reach me. You can of course replace “legacy” with “simple PHP mail script” or “shop frontend” if you like, as administrators or developers of these systems are apparently completely unaware of the bad job they do, if they fulfil the requirement “hey, the user should get this notification email, but ensure that he won’t spam the support with questions about it, so use an invalid address…”
You know what follows: The novice, or sometimes also not so novice developer / administrator, simply goes ahead and sets `noreply@host.com` as `From:` address. Especially in shared hosting environments there is usually an MX server configured for the hosted domain which allows local relaying, so sending a mail from a PHP script like this
mail("joe@otherhost.com", "Hello", "It works!",
"From: noreply@host.com\r\n");
seems so simple. Of course most of the time it gets completly forgotten to give the mail server of the `host.com` domain a notice that there is suddenly a new (bogus) mail user available within one of his managed domains! So how do you fulfil the “don’t spam the support” requirement then?
Well, the simplest way is to use an existing mail address which is known within the sending mail server and then also add a `Reply-To:` header to your mail which may then contain the bogus address. If the user clicks on “reply” in his mail client, this reply-to address will pop up in the `To:` field and you practically achieve the same effect.
But probably the best way is of course to convince your management that it should not ignore customer inquiries by stupid procedures like this…
As a customer of several online services I have encountered this and similar mail problems a lot in the past. I cannot remember exactly when I actually stopped informing the individual webmaster or support team about the problems they had with their mail setup, simply because my inquiries had been ignored most of the time. See this blog post as a silent rant for all the crappy configured setups out there.
