Thanks, your list is somewhat helpful. The problem I have is that Exim lets bounced emails sit on the server when they will never be returned to the sender (the spammer).

Example: The following email was caught by Exim as containing a possible virus. BUT, it trys to deliver it back to the sender???? WTF? Why on earth would Exim be configured to do that? That is completely dumb, IMHO.

---------------------------------------------
1BsSLm-0003mX-9Q-D
This message was created automatically by mail delivery software.

A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:

tony@someone.com
This message has been rejected because it has
a potentially executable attachment "message.scr"
This form of attachment has been used by
recent viruses or other malware.
If you meant to send this file then please
package it up as a zip file and resend it.
--------------------------------------------

So the above email just sits in the queue because it cannot be delivered back to the spammer or the virus that sent it. This makes no sense.

After doing that, set default address for the mail account to ":fail: no such user" this will reject all mail that does not have an email address setup on the server or a forwarder, this is done at the MTA level, so the mail never gets onto the server.

Also, nice feature in WHM Tweaks is ability to set all new accounts to :fail: for default email, so that usually helps with all the new accounts.

Beg to differ. MailScanner is by far and away more configurable and customisable. Exiscan might be lighter on server resources, but better it is not.

The dictionary attack ACL's will not necessarily stop your queue building up, either.

You should already have the verify=recipient in your exim.conf

set all new accounts to :fail: for default email

Click to expand...

No, that's what puts bounces in the queue You should set default addresses to :blackhole:

Now, to answer your actual question, that message is coming from /etc/antivirus.exim, you should either modify that to stop it bouncing emails, or do away with it completely (which is what I do):
cat /dev/null > /etc/antivirus.exim

The default confiugration of mailscanner will simply ADD crud to the queue, not reduce it.

Click to expand...

Actually, it's the default configuration that cPanel published in their ancient layer1 release that was really badly configured. The default MailScanner configuration file is OK, but with only a little bit of work and your queue should not be affected by it at all.

No, that's what puts bounces in the queue You should set default addresses to :blackhole:

Click to expand...

Jonathan, you know way more about exim than I do, but won't setting it to :blackhole: accept all of that junk to the server? Using those modifications from cvf.net my server refuses the connection with :fail:. The stuff does not get into the queue because it never makes it that far.

It was my understanding that :fail: and :blackhole: were the same, i.e. both accept the mail then ditch it, but :fail: sends a bounce back. I didn't think it was the same as an SMTP protocol bounce such as a RCPT failure.

I've checked the exim spec and the mailing list and cannot find anything to contradict my understandings. :blackhole: and :fail: happen at the same stage in the lifecycle of an email, so using :blackhole: stops bounces going back to (potentially) innocent parties, whereas :fail: does not. The only additional thing about :fail: is that the message following it is used both in the bounce and in the case of a RCPT or VRFY failure, but this has no impact on what we're discussing.

It's sad, really. Bounce messages used to be very helpful - they told you when a mail didn't get there. Nowadays, they're nearly always bounces from spam you never sent

When you use :fail: no such user, it will not allow the email onto the server and rejects it at the MTA level... Thus there is no que buildup... Instead it builds up on the server that is sending the mail, cause it will not go anywhere.. Either the TO or FROM of the email... *** but this can be good, cause it would hopefully alert someone that someone is spamming from thier server... or at least we can hope!

OK, I'm now going to eat humble pie and apologise to those I've misled and those I disbelieved. After quite some testing, I've realised the error of my ways and indeed the following has worked wonders on one of my servers where one particular customer has been inundated with spam:

replace :blackhole: :fail: -- /etc/valiases/*

The dictionary attack ACL that I put together from various sources is now working much better too, thanks to the prevelance of RCPT failures

PartnerNOC

I have one domain on my server I think receives at least 100,000 dictionary attacks emails a day (don't these spammers give up its a pleasure to watch their spam go nowhere and see them get locked out using none of my bandwidth)http://linux.cvf.net/cp_eximrules.html
works beautiful but I do not use all of the rbls

another that is a virus magnet
that's why I recommended exiscan mailscanner was using way to much resources scanning them why waste the server resources its a "virus" and turning off the notifications would not let that occasional legitimate sender know that their mail went into the trash