qmail patch to reject invalid email at the smtp layer


I was wondering what it would take to get a patch into the interworx qmail rpm so qmail will reject mail to invalid addresses at the smtp layer.

This would be great for spammers that use a dictionary of words to bombard a mailserver with spam. By rejecting it at the smtp layer, it never clogs up the mail queue, and those that are running spam/virus checks are not wasting cpu time on mail that is never going to get delivered.

One such patch that seems to do this is located at:


named qmail-realrcptto patch

Yes, this one would be really great.

Another day a spammer sent to my server 20.000 (yes, 2 + four zeros) e-mails, using my domain with a dictionary.

The only problem with this is spammer s can validate e-mail addresses. If htey forge From (which they almost allways do), they don’t know what happens to the span when they send it.

If you reject at the SMTP server, they know as they are sending what addresses are good and what are bad. They can validate e-mail addresses and know if they keep sending to certian ones someone will get it.

Yes, I’m aware of this possibility. But as things are today, they keep sending to all addresses. And as they use fake return paths, you waste resourses bouncing the e-mail back and reciving the bounce back to you some time later (“This is the qmail-send program at XXXXX. I tried to deliver a bounce message to this address, but the bounce bounced!”).

I agree, this is a valid concern. The patch you mentioned won’t work with InterWorx since it doesn’t understand vpopmail, but there is a patch we’re looking into called chkuser.

There is something you can do about the double bounce messages immediately though.

run the following commands as root:

echo '#' > /var/qmail/alias/.qmail-dev-null
chown alias.nofiles /var/qmail/alias/.qmail-dev-null
echo 'dev-null' > /var/qmail/control/doublebounceto

it seems to be great

There is something you can do about the double bounce messages immediately though.

run the following commands as root:

echo '#' > /var/qmail/alias/.qmail-dev-null
chown alias.nofiles /var/qmail/alias/.qmail-dev-null
echo 'dev-null' > /var/qmail/control/doublebounceto

Paul, isn’t it the same think to only let a blank field or only # char in /var/qmail/control/doublebounceto ?

For my personnal concern, do you absolutly need to have an existing alias to pipe all double bounce messages to a null email ?



Knowing qmail it could work with just the # in there Pascal, but every example I’ve seen uses the alias.


Ok, so it should have a reason why :slight_smile:

If every example uses the alias, I’ll use the alias :slight_smile:

Thanks Chris and Paul

[SIZE=2]So what’s our final solution to filter out the double bounces?[/SIZE]


There’s an option in there to disable double bounces.

chkuser implemented??

Just checking this discussion for the first time. Wondering if this patch was ever implemented in interworx (latest update). We have been hit by two smtpd attacks where they are doing dictionary attacks. Of course the qmail we all know and love accepts every darn message before it denies it! So, valuable server resources are taken up dealing with it.
We have been looking at adding a Barracuda Spam Filter to help offload the huge loads we get on SPAM (having almost 5000 email accounts) but they will not work to deny smtpd attacks if this patch is not in place because qmail will accept all the messages before bouncing them.
Sorry to be so verbose on a simple question… was this patch implemented yet? Thanks.


I would also appreciate some info on this, as we want to enable Dynamic Recipient verification for our SPAM checking, and without it rejecting at the outset of the SMTP transaction, it cant work.



Yes, the chkuser patch has been added. You enable it on a per-domain basis in SiteWorx, by turning “bounce on”. Site Services->E-mail->Overview on the menu.


nothing cooler

There is nothing cooler than asking something and finding out that you already have it! Thanks guys for the amazing product! Greatly appreciated.

Ahh… perfect thank you Paul :slight_smile:

Just tested it, and got an email back from the SPAM Server (which is what we were aiming for), saying:

<test@emailaddress.com>: host servername.ew-servername.net[87.117.XXX.XX] said: 511 sorry, no
mailbox here by that name (#5.1.1 - chkuser) (in reply to RCPT TO command)

Perfect :wink:

smtp attacks seem to be a major drag on resources for me as well. I enabled bouncing in SiteWorx but the help file states the following:

This is where you can define what happens when an e-mail is sent to an address at your domain that does not exist. The choices are:

  1. Send a “bounce” message back to the sender informing them that the e-mail address they sent to does not exist
  2. Silently delete the message without informing the sender that the e-mail address does not exist
  3. Forward these messages to another e-mail address, called a “catch-all” address.

I want to do #2. How do I accomplish this?

it is pretty easy to accomplish #2. You need to log in to each of your user accounts to do this. Once logged in to a user account, cick on Email --> Overview --> and then you will see the ‘Bounce Messages’ field will either be set to On or Off. If the bounce is set to ‘off’ then qmail will silently delete all messages. When set to On, this is where the patch comes in to play and it will bounce all messages that do not match a valid recpt.
Here is the problem with it comes to an smtp attack though. If you have set it to black hole these messages (silently delete) the problem is that you can be overloaded with an smtp attack because qmail has to process every bogus email account. It runs each message through virus and spam filtering and realizes that account doesn’t exist. What Paul said, by implementing the chkuser patch into qmail is that qmail checks for a valid user before even accepting the message. If the account doesn’t exist, it can bounce it BEFORE tying up your server resources. So, in the case of an smtpd attack, you are better off bouncing emails than black holing them in my opinion.

Thanks for that. We’ll see how it helps.


Can you just confirm that the chkuser does succesfully allow email addresses which are setup as aliases.


Mailbox: firstname@domain.com
Alias: firstname.lastname@domain.com

These would both be classed as valid recipients by chkuser?