email queued Limit...

[PWSowner]

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.

[/bin/bash.org]

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 ).

#!/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.

[yaax]

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.

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.

[yaax]

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 ).

#!/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?)...

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:

#!/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

#!/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/d...l/spec_49.html

[/bin/bash.org]

You script is doing same elimination of entire exim mail que.

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.