I suppose every mail admin has worked through this. Here's my read, and tactic. The context is thatretried 240 times. Is there another, simpler method I can use to selectively force messages in the queue to be returned for delivery failure?
1) users send mail expectating it to be delivered fairly quickly.
2) ime, their expectation is met, because most mail is delivered to the recipient's mail server in well under a minute.
I see mail lingering in IMgate's queue for under an average of just 10 secs. This is the from the protocol point where Imail accepts inbound mail, queues it, and then delivers the mail to the next-hop MTA, releasing IMGate for responsibility for the message.
Because IMGate is involved in some very high volumes (both valid and spam mail), I'm always interested in the scalability issues, just as any Imail admin should be. And since a lot of IMGates accept mail per-domain, and not per-user, IMGate can see a lot of bounces of inbound by the mailbox server for non-existent users. When IMGate must then generate the mailer-daemon msg to the envelope sender which is forged or otherwise undeliverable, IMGate's queue can, as you see also with IMail, become horribly clogged up with 1000's of non-deliver bounces.
So here's what IMGate standard config has been doing for several months, and so far, I haven't heard any negative feedback.
1. Max queue lifetime is 2 hours.
2. At one hour, IMGate generates a "mail delay / still trying" warning to the sender.
I won't address IMGate's queue run approach other to say it's "exponential backoff" rather than Imail fixed, linear x retries every period. And there are many of other highly intelligent tactics to queue processing, since queue processing is the performance basis of MTA processing.
The above settings address the problem you see:
1. At one hour, senders are informed at one hour that there is delivery delay. afaik, Ipswitch hasn't slipped in this nicety to Imail 7. too bad, highly recommended.
2. At two hours, the message is bounced to the sender as undeliverable. This obviates the nasty surprise for the sender, eg, 12 hours, 1 day or 5 days later, that the message was not delivered.
I think these are user friendly settings. No complaints so far.
From, IMGate�s POV to which I must also "be friendly", those troublesome non-deliverable bounce messages, running into the many 1000's when operating with a 5 day timeout, simply disappear in 2 hours, keeping the deferred queue buildup small, and reducing immensely queue processing overheads.
For the situation where the mail that we relay for our clients' mailbox servers, when our system monitoring shows their server is refusing mail, we find out why, and if the foreseen delay is going to more that 2 hours, we simply change the 2 hours to 2 days for the episode and then back to 2 hours when the problem has passed.
Len
To Unsubscribe: http://www.ipswitch.com/support/mailing-lists.html
List Archive: http://www.mail-archive.com/imail_forum%40list.ipswitch.com/
Knowledge Base/FAQ: http://www.ipswitch.com/support/IMail/
