Len, I agree with you that the lack of "mail delay" and variable delivery times are major IMail shortcomings. Heck, even M$ has that in their simple W2K SMTP.
Yes, the major issue is the non-deliverable bounces that are forwarded from their mail servers after 3 attempts. Unfortunately, since I'm not able to monitor the status of their mail servers and I don't always have access to my servers (on an airplane, at a fire, etc.) I have to leave the queue time high enough to handle a long holiday weekend without intervention. I do kill a large number of the bounces with Declude JunkMail. What would be ideal of course is a system that could differentiate between the store and forward which I'd like to hold for up to 5 days and the outbound relay which I'd like to kill after a couple of hours. I could always add another server to the mix and use that for the outbound, which is what I'll probably end up doing in the long term. Thanks for your thoughts. George -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Len Conrad Sent: Monday, January 27, 2003 4:16 PM To: [EMAIL PROTECTED] Subject: Re: [IMail Forum] Forcing Rejects >retried 240 times. Is there another, simpler method I can use to >selectively force messages in the queue to be returned for delivery >failure? I suppose every mail admin has worked through this. Here's my read, and tactic. The context is that 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/ 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/
