Bounce message control

Don?t think there is a good solution to this, but I?ll ask anyway 

I have a client on my server that gets about 10-20 emails in burst about every 5-10 mins or so. These are emails to This clogs up my qmail with bounce messages that will never go out because the reply-to addresses are also fake.

Is there any way to somehow have the bounce on, but distinguish valid reply-to emails vs spam ones? I was thinking of maybe a DNS lookup on the name, but if the reply to email is a valid domain (just bad email) that wouldn’t help much. Plus that might put more of a load on the server than just having the email queue clogged up.

Any ideas?

For the time being the best solution is to disable bounce messages for that domain. We are exploring other options to combat this issue but right now that’s the best thing. If that makes the client unhappy, tell them that if the queue clogs up too much it could start affecting all mail delivery, and I’m sure they don’t want bounce messages on that badly.


I just thought of something that might work.

The plan…

Make the queue life much shorter than the default 7 days for emails that have the subject “failure notice” (ie. bounce messages). I know Qmail doens’t allow you to set different Q times, but this could be done using a cron job that runs every 4 hours or so. There should be a way to see how long the message has been in the Q for and read its subject. If subject == “failure notice” and Qlife > 4 hours delete the email.

I haven’t really looked into this idea too much, but just wanted to get some thoughts.

I would say that the best way to deal with this (as any MTA should if possible) would be to have qmail do a lookup on the recipient address. If the recipient is not valid on the mailserver it will reject the message. The bounce would be the sending MTAs responsibility.

I know this is possible with postfix and recipient maps but I have no idea how qmail could do this together with IWorx.



There are a few patches available that will do this. Near the top of our list is the chkuser patch, and integrating it (or something similar) with the IWorx setup is definately on our todo list.