email queued Limit...

You can make very simple bash script like this one:

Code:

cd /var/spool/exim/input
for file in *
do
rm -rfv $file
done

cd /var/spool/exim/msglog
for file in *
do
rm -rfv $file
done

And put him run once per day from cronjob.
This script will delete all exim que once per day.

 

That's an extremely bad idea. You will lose a lot of legitimate email that way.

If you're getting a lot of email in your mail queue, then make sure that:

1. No-one is using :blackhole: in /etc/valiases/* if they are, replace them with :fail: instead

2. Make sure mail accounts are not over-quota and enable the option in WHM > Exim Configuration Editor > Discard emails for users who have exceeded their quota instead of keeping them in the queue

Lastly, update exim to make sure you don't have an older buggy version:

/scripts/eximup --force

You might need to initiall empty the queue using WHM > Mail Queue Manager > Delete all messages in Queue, but void doing so if you can. If you do use that, it's best to stop exim while running it to avoid losing email.

 

I have this set but the mail comes in, then a bounce message is generated (for over quota). This creates problems for incoming mails sent from various lists which do not accept a bounce message back. These mails stay in que till they are dropped on reaching the 8th day.

Anup

 

Then they're not causing much of an issue and you can leave them there. That's what the mail queue is for. It's not necessary to have an aesthetically pleasing mail queue, it is important to not remove legitimately queued email from it and simply deleting it does just that.

 

The point that i was trying to emphasize was That the setting in WHM for Overquota is not respected as far as que handling is concerned

Anup

 

Yes, it is. It's discarding the email and not attempting delivery to the recipient, which is exactly what it is meant to do. It also must reply to the originator to comply with the RFC's which state that you must inform the originator if you fail to deliver an email. If you want to break the RFC's you'll have to head on over to www.exim.org to see if there's a hack to do so.

 

2005-11-29 12:49:42 1Egzm3-0005U0-Ll == user@somedomain.com R=virtual_user T=virtual_userdelivery defer (-22): mailbox is full (MTA-imposed quota exceeded while writing to tmp/1133248782.H717675P21086.host.domain.com).

Does this mean it is discarding or It is attemting to deliver it once.
If such mail account has a forwarder set to some other account elsewhere, shouldn't forwarding also fail? Or is it that forwarding will happen despite the fact that mailbox is full.

Anup

 

I think that deleteing entire mail que once per day is not so bad.
You can choose day time when your server has less activity and cleanup mail que then.
Normal emails are going through within few seconds after they were sent, and 99.99% of emails staying a long time in the que are some junk replies of failed delivery, spam etc.

The chances to eliminate some normal email are very very low this almost zero percent, especially if you will clean up mail que once per day only in the hour when almost all server users are not active and server has almost no activity. So the clean up process will take just few seconds and in that time no one will sent email so it will never delete legitimate emails this way.

 

Big mail que is not just problem with aesthetically pleasing view. Long mail que will cause big delays with mail delivery. Server users may start to complain that they have to wait few hours between sending and receiving any email message.
All these problems can be prevented only by safe elimination of entire mail que.

 

No, that's also not true. A big mail queue does not mean slow email delievery. You really need to understand better how mail queuing and exim works. Email that doesn't require queing will be processed immediately. Also deleting the mail queue (which also includes currently processing email) is still an extremely bad idea and should never be recommended to anyone. You have a mail queue for very good reason and you should leave it well alone unless you fully understand the implications of deleting it. You should not assume that just because email is queued that it is undeliverable.

 

About delay in mail delivery due to long que, I know from my own experience. You may try to tell me anything you like but from my experience I see that problem start when exim mail que became too large usually bigger then 1000 messages - mail delivery time start to became problematic slow.

And also I cannot see any good reasons for email message to stay in mail que more then few hours. If some email message stay in que more then 24 hours it mean that this message is undeliverable. Ok , I can assume it may be waiting until mailbox user will free some disk space or may be it is waiting until recipient server will became accessible online.
But in any case long staying in que emails are really undeliverable from my point of view.

 

Then you really need to understand why emails can get queued. I would suggest you read up on SMTP servers and queing to understand it better as you clearly don't. The general standard which all SMTP server rely upon is that email will queue for at least 4 days and keep trying in the meantime. If you bypass this, then you will lose legitimate email and also risk non-delivery of your own email if you use your server for outgoing SMTP. That's a simple fact.

If that risk is fine for you, then go ahead and do it. However it is reckless to recommend it to anyone else.

 

In fact I am hosting more then 1000 clients on few Cpanel servers with local smtp and with cleaning up mail que once per day. I am doing this more then year now and still did not received any complaint about loosing legitimate emails. While before using this script to clean up mail que, I was receiving constant complaints about slow email delivery time and then I was forced to delete mail que manually - only this way it was making emails delivery time to normal value.

If someone afraid to use this way, it is his own decision. But I am sure for many servers it is only possible and decent solution to resolve problems with slow email delivery time.
Of course it is some risk and you have some very very low chances to loose sometime some single legitimate email, but comparing so small chances of so small problem with sure problem - of slow delivery time. It is clear then preferrable solution will be just erase entire mail que once per day in this case.

 

No, tt really is not the only solution, see my previous bulletted post. A properly configured SMTP server should only have a small queue of a few hundred emails at most. If it is larger, then you have configuration or spam problems that you're not addressing . Yours is certainly not a decent solution in any way.

 

I have to agree with Chirpy. The mail queue is for a reason and it should NEVER just be deleted. If the queue is large, it needs to be looked at to find out why. Several months ago our queue suddenly started getting large so I looked and our newest customer changed the default :fail: to :blackhole:. I changed it back and notified the customer with an explanation for the change and the queue was back to normal.

If a queue is large and the server owner can't figure out why, have someone else, like Chirpy, look at the server. I bet he can find out why it's so big.

 

I'm not entirely comfortable with the idea of a completely arbitrary queue deletion. I do agree that queue maintenance is necessary, however. Something that I do is create myself a couple of little scripts to help out, using the MTA's own management tools where possible. Here's one I use for exim (it's quick'n'dirty, so don't laugh - submit a patch ).

Code:

#!/bin/bash -
# remove_null_mail.sh
# Removes queued mail with a null ( <> ) recipient

mailq () {
        exim -bp
}

for line in `mailq|grep '<>'|awk '{ print $3 }'`; do /usr/sbin/exim -Mrm $line; done

Basically, as chirpy said, figure out what's causing the problems and deal with that if possible. There is no way I would delete the entire queue automatically. I especially wouldn't delete the files directly while a native queue maintenance tool exists. As an aside, often the queue can be a good barometer of other issues, too (battsl1005@aol.com anyone?)...

Something else that I don't think I've seen in exim that is helpful for big mail volumes - an equivalent of sendmail's FallbackMX directive. This delightful tool adds an "additional" MX RR to the destination domain's MX list (or, just adds one if none exist). You would set this "additional MX record" within sendmail's config to point at another MTA. What happens when delivering the first time is, sendmail does an MX record lookup on the destination, and adds the FallbackMX host as last priority. sendmail then tries each MX in turn (as it should). If all the real MX hosts are offline/unreachable, the message gets delivered to your other MTA. This has the effect of transferring all your delayed/dodgy email to another server which will keep trying to deliver it, and keeping the queue clean (and fast) on your main server/s.

 

And now you see if you have few hundred of customers on server, you will frequently find that someone will change default :fail: to some his email or to :blackhole:
And you will need to take care about all such changes which you cannot prevent you customers to do. Also this way you will not allow your customers to have catch-all mailbox as on this mailbox is frequently arriving a lot of spam which frequrently will stay in mail que many days and will fill out mail que.

 

You script is doing same elimination of entire exim mail que. However in case of huge spam attacks I prefer to disable exim and then clean que by direct files deletion.
Also in case of high server load it is preferable to use more simple ways to clean que with as less commands number as possible.

Btw, you can use this script which will delete all emails in que that older then 1 hour:

Code:

#!/bin/bash -
# remove_old_mail.sh
# Removes queued mail with messages older then one hour

mailq () {
        exiqgrep -o 3600 -b
}

for line in `mailq| awk '{ print $1 }'`; do /usr/sbin/exim -Mrm $line; done

Or this script to delete all messages with a null ( <> ) sender

Code:

#!/bin/bash -
# remove_null_sender.sh
# Removes queued mail with a null ( <> ) sender

mailq () {
        exiqgrep -b
}

for line in `mailq |awk '{print$1 " " $3}' | grep '<>' | awk '{print$1}'`; do /usr/sbin/exim -Mrm $line; done

Also you can see many useful exim options here:
http://www.exim.org/exim-html-4.50/doc/html/spec_49.html

 

No, it doesn't. It behaves the same as the one you posted. If your queue is full of <> mail, though...

Anyway, thanks for the tips on exiqgrep. I'm a sendmail refugee and am still coming to grips with exim. Your examples are exactly what I was advocating.