Some miscreant is using non-existent accounts on my domain as a forged sender for spam emails (i.e., sdfhdfsg@mydomain.com).

All the out-of-office and spam rejection emails are coming back to me (since my domain is set up to pass me anything addressed to my domain name).

The domain email is actually set up to redirect to Gmail, which is doing an admirable job at coping with the deluge (50k+ emails a week at least) but there's still a lot its not filtering.

The result of this is that I now no longer have my email for this account coming to my iPhone, as its incessant.

What can I do to reclaim normality? Not having all domain email come to me is the first thing that springs to mind (i.e, if the account doesn't exists, ignore it).

Anyone else got further advice?

Edit: Suddenly occurred to me - is this better asked on ServerFault?

migrated from superuser.com Sep 2 '09 at 16:05

This question came from our site for computer enthusiasts and power users.

  • Yes, wait for it to be moved to ServerFault rather than repost though. – djhowell Sep 2 '09 at 15:47
  • Phew! Luckily I've not submitted the form on SF yet! :-D – Rob Cowell Sep 2 '09 at 15:51

Simple answer: don't have a catch-all on your domain.

In fact, don't accept mail on your server for accounts that don't exist, full stop. Just reject it outright, during the initial SMTP transaction. This is especially important when you have a front-end SMTP "proxy" server that does things like anti-virus, anti-spam etc, before passing clean(er) emails to an "inner" SMTP server that knows what users have mailboxes (e.g. MS Exchange). Outer proxy servers are often set up to accept email for an entire domain, without knowing which users exist, so they accept mail to anyone at your domain. Only when they realise that the user doesn't exist, they will generate an NDR. This can often be going back to an invalid address too, or to some other innocent victim.

You will also benefit here from not sending out NDRs for spams to invalid addresses on your domain that your "inner" server rejects. I've actually seen ISPs mistake these NDRs for outbound spamming abuse.

  • 4
    +1. btw, i don't blame ISPs for seeing those NDRs as spam - backscatter IS spam, it causes the same load problems as direct spam. it is also evidence of an incompetently-run mail server that deserves to be blocked. – cas Sep 2 '09 at 22:33
  • I suspected the case. Thanks for confirming it and providing additional info – Rob Cowell Sep 3 '09 at 8:03
  1. Don't do *@mydomain -> something. That's a recipe for what you're experiencing.
  2. Make sure that your mailserver knows what valid users exist, and rejects mail (at SMTP time, not afterwards!) for users that don't exist.

Also, Consider using something like this (postfix formatted) smtpd_recipient_restriction

<>          reject_rbl_client ips.backscatterer.org
postmaster  reject_rbl_client ips.backscatterer.org
  • +1 catch-all addresses are a really bad idea. they are a spam and back-scatter multiplier. you get the garbage for every randomlocalpart@yourdomain that spammers use. – cas Sep 2 '09 at 22:29

On the previous posters advice to reject any email at SMTP level that's not a know user: This can be used by spammers to detect whether an email address on your domain is valid.

Of course the alternatives are

  • accept the email (bad),
  • silently drop it (bad if it's a legitimate mail with a typo in the address)

so it's a typical "damned if you do, damned if you don't" situation that appears everywhere where email is involved...


The correct solution to stopping backscatter without allowing harvesting of emails is to reject email for nonexistent users, but also use fail2ban to block directory harvesting attacks. So after the first few in a row from the ip it will get blocked.

This gets the best of both worlds. By rejecting during SMTP, backscatter is prevented. By using fail2ban to firewall off misbehaving machines, the directory harvesting attack is stopped. And by rejecting typoed legit email, the person realizes something went wrong.

  • 1
    Such blocking can lead to false positives. You need to ensure that the blocking always is performed using error codes indicating a transitional error. You need to ensure it has a very clear error message indicating why the transaction was blocked. And you shouldn't let the block persist for more than a few minutes at a time. – kasperd Jan 17 '16 at 23:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.