Spam via SMTP Non-Delivery Reports

I have modest email needs, so I use the default SMTP and POP3 services in Windows Server 2003. Although I have email relay disabled, spammers are still managing to send spam through my SMTP service -- via non-delivery reports!

This is a companion discussion topic for the original blog entry at:

Would setting up a catch-all account do what you wanted?

Don’t know if this is of any use, and I haven’t tried it because I don’t run a 2k3 machine, but it may be useful.


I’ve been getting bounces for mails I didn’t send, so I assume it’s probably something like this. Interestingly, some ISPs appear to be wise to the tactic and are not including the original text of the bounced message. This makes it pointless to bounce off their servers for spam purposes. Of course, it’s unlikely the spammers will ever see that their message wasn’t delivered. But that never stopped them anyway.


This is a shameless plug, but you might consider using Majodio Mail ( It has the following features:

• Email verification of SMTP from command to ensure that whoever is sending the email is legitimate. This is accomplished by doing a reverse DNS lookup on the IP and seeing if the domain matches (at least partially) the from email address provided
• API support for .Net 2.0
• Plugin manager to allow for additional functionality if desired.
• DNS Black List (DNSBL) support to reduce Spam.
• Email Spam filtering based on the DNSBL server used.
• Configurable encrypted email storage for security
• Support for MIME 1.0 parsing.
• Multi-threaded SMTP/POP3/Logging servers
• Multiple domain support
• User Aliases with multiple destination mail boxes
• The ability to define banned IP addresses
• Includes a friendly user interface to make configuration effortless
• Real-Time monitoring of all services (scrolling event log)
• Real-Time statistics (counters) so server administration is a breeze.

But the best feature of all is that it’s FREE!

Brian Swiger has told me that he would like to add a Web based UI so hopefully that will be coming soon. You can download the latest version of the server from:

The documentation can be found here:

If you do download it, let me know what you think. You can contact me at

egad, that uucp@ address…

i believe i’m getting the exact same spammer. i’ve just been too lazy t analyze what was happening - thanks for the heads-up on that. i’ve been using Merak’s mail server ( and it has not been blocking those messages. i will investigate the options and see what i find.

for home use on and off i’ve been using lumisoft’s mail server (free, open source, c#). i’ve written filter plug-in’s for it in teh past using the provided interfaces. that may do the trick.

What are the repurcussions of breaking that RFC? Seems to me like the good is outweighing the bad here.

Would setting up a catch-all account do what you wanted?

The catch-all script indeed DOES work. It’s not technically compliant, since emails to unknown users now no longer result in a NDR… but I’m willing to live with that.

A better solution would be to send the 550 and use a tarpit to slow down dictionary attacks, but this lets me stick with the existing built-in Win2k3 services.

hrm. i’m not seeing a way to do that in Merak MailServer.

seriously, i’ve been tempted to write my own mail server for my personal, more light-weight needs. i just feel so dirty writing a mail server in the year 2006, especially when it’s something that i feel needs to be scrapped and re-written as a protocol.

MailEnable Standard Edition is free and rejects unknown recipients prior to accepting the message.

Or you could stop being lazy, but a P100 with 32 mb ram and a mere 1gb HDD on ebay, put any linux flavor and configure qmail with LifeWithQmail document. It can take 1 hr. It will work forever.

That’s what I did :slight_smile:

You should consider XWall for the mail server. It has every kind of spam filter including Grey Listing which is the easy way to stop spam before it can even be delivered. Exactly what you are asking for.

Are you saying that Microsoft Windows 2003 is improperly handling the SMTP protocol? The software from Microsoft, the guys who promised two years ago that this year there will be no more spam? Nooo… That’s impossible!

Irony away, a properly functioning SMTP server should NEVER generate post-delivery NDRs. The server should check whether the account in RCPT TO exists, and if it does not, it should NOT accept the message, but return a 5xx code (eg. “554. Recipient address unavailable.”). Then the NDR is generated by the sender SMTP server, so an NDR is indeed created, if, obviously, the sender is a real SMTP server.

I don’t know about MS Windows Server 2003, but look harder for a solution, and if not, publicize this fact as much as you can. If this is the case, MS Windows Server 2003 is UNUSABLE as a mail server, and if you continue to use it, you’ll end up in DNSBLs listing improperly configured MTAs. Even Spamcop these days accepts reports of incorrectly sent NDRs.

Irony away, a properly functioning SMTP server should NEVER generate post-delivery NDRs. The server should check whether the account in RCPT TO exists, and if it does not, it should NOT accept the message, but return a 5xx code

The problem is that the SMTP service and the POP3 service are written by different groups and have different interfaces. There’s no integration (eg, checking to see if the mail account exists before accepting the message). Even though both services come “in the box”…

Would setting up a catch-all account do what you wanted?

Hmm. This might work… I was creating accounts manually for commonly spammed aliases, if I had a single local account that accepted ALL unknown email, that would fix my problem!

I’m having the opposite problem, lots of emails being sent (probably through some open relay) with random @{mydomain}.com return addresses. I’m seeing hundreds of ‘no such user’ and otehr error returns per day to zzdhtyej@{mydomain}.com etc. I have no clue how to stop this since I have a catch all which is why they all end up in my account.

Another option is to reject the mail if the MAIL FROM: address’ domain doesn’t match the sending host’s reverse DNS lookup (and HELO domain). This is something people sometimes do against spammers, but it certainly violates RFCs and will also block a whole lot of legitimate email too, but it’s possible.

The correct way to do it is to send a 550 back if the RCPT TO: address doesn’t exist.

I’m not familiar with Windows’ email services at all, only Linux. Do email addresses tend to correspond to user accounts?

There is always some new trick to get around the newest filters. accept and move on.

Oh, and get a real server. That stock crap that comes with the OS isn’t suitable for more than just concept testing, never EVER point it to a public interface.

I use ArgoSoft MailServer with MailFilter Pro, and it works like a champ.

I’m going to try out SurgeMail. It’s free for personal (5-user license) use.

I’ve been hit with NDR spam recently, though at a pretty low rate.

If I had the time and inclination, I’d be rolling my own SMTP command sink:

I imagine that it’d be really straightforward to check for the presence of a POP3 account (ADSI?) on RCPT.

Surprised I didn’t find any other hits for SMTP event sinks that did this though, so perhaps not…

The SMTP server could be on a different machine to the domain controller, which contains the e-mail addresses. To avoid wasting time on the SMTP connection, Windows doesn’t do the lookup until after accepting the message. This also has the side effect that an attacker can’t determine whether an email address is genuine or not (since the server accepts any addresses). It’s perfectly entitled to do this because SMTP allows servers to accept messages for relaying to other servers.

We’ve been blocked a couple of times by our ISP for sending viruses. We use their outgoing mail server using the Smart Host feature in Exchange - this saves the DNS lookup traffic that occurs to look up the next hop, and reduces the number of connections, useful on a low-bandwidth connection. On investigation we discovered that it wasn’t actually originating with us: in fact what was happening was that viruses were sent to non-existent mailboxes, and Exchange was attaching the original message (containing the virus) to the NDR. I got around this by limiting the size of the NDR that would be generated to a few hundred bytes, which causes Exchange not to attach the original message in almost all cases.

You might be able to prevent it by using the registry key documented in KB article 842528: