> So I would recommend a minimum of 16 hours.
I have to disagree with Scott here.
We rarely set our pure-IMail installations for more than 4 hours of
retries (16t/15m or 8t/30m), and often go as low as 2 hours. The
reason? IMail is unable to send interim delivery notices to senders,
and we don't think more than a four-hour delay before any notification
is reasonable for most of our clients. It's true that we do serve an
overwhelmingly corporate clientele, which means that knowing that mail
hasn't gone through by end-of-business or
end-of-some-claimed-deal-window is very important.
When using MS SMTP as a smart host, for one counter-example, we will
usually bump up the maximum queue lifetime to 8 or maybe 20 hours,
since MS SMTP has a nice backoff-and-notify algorithm. But in so
doing, you have to be aware of the additional traffic that such
interim notices will generate and size your hardware accordingly. We
are committed to building in a lot of headroom on any mailserver we
deploy, and others may not have taken such precautions.
On a related topic, if you're providing MX services for specific
separate mailbox servers _and_ wildcard outbound SMTP from the same
IMail server, you have to be careful to tune the queue lifetime for
the worst-case scenario. For example, if in your backup MX contract
you promised not to kick back messages until a mailbox server has been
down for 48 hours, then you unfortunately have to increase the queue
lifetime--a global setting--to 48 hours, meaning you're not providing
a best-fit for both functions. Using a dedicated IMail box for your MX
domains is one way to fix this; another way is to deploy MS SMTP as
both an upstream smart host, freeing the mailbox server up for other
tasks, _and_ as your MX box, using two or more MS SMTP virtual hosts
with different queue lifetimes and retry delays for each function.
Very slick.
Of course, this all does depend on the particulars of your local and
known remote user communities, as well as on how much your hardware
can handle at one time, but I would not say that 16 hours is
applicable across the board by any means.
--Sandy
------------------------------------
Sanford Whiteman, Chief Technologist
Broadleaf Systems, a division of
Cypress Integrated Systems, Inc.
e-mail: [EMAIL PROTECTED]
SpamAssassin plugs into Declude!
http://www.mailmage.com/download/software/freeutils/SPAMC32/Release/
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/
