>I frequently have problems with IMail in that it often fails to deliver
>mail, and mail starts to stack up in the \spool folder.
>
>I typically send 18,000 email messages per day to members on my
>mailing/subscription list. It's an automated process that occurs at
>3:00am each day, and Imail handles the delivery of all these messages.
>
>Typically, all the messages are delivered promptly, with a few stragglers
>hanging around the \spool folder for a few hours, but there are some days
>when 10 hours later, at noon the same day, my \spool folder contains over
>10,000 files!
One piece of advice would be to batch the E-mails -- instead of sending
18,000 E-mails, send 900 E-mails each to 20 recipients. Then, in a
worst-case scenario, you'll have less than 2000 files in the spool (each
E-mail has 2 files).
>I have my IMail Administrator configured to "10 tries before returning to
>sender" and "Queue timer" set to 30. This would mean that any
>undeliverable mail should be sent back to the sender after 5 hours have
>elapsed. If this is true, then why at 11:30am do I still have thousands
>of SMD files in my \spool folder, all with time stamps of 3:00am through
>6:00am?
Because you've overloaded IMail. When the first queue run starts, there is
one process that has 18,000 E-mails to deliver. It will take many hours
for that one process to deliver all those E-mails. So 1/2 hour later, when
another process is started to work the queue, most of the E-mail hasn't
been attempted once yet.
If you have IMail set to re-try each E-mail every 1/2 hour, but you have so
much more E-mail than it can deliver in 1/2 hour, it just can't work as you
expect it to.
>Any insight on what might be wrong?
Several things.
1. Having up to 40,000 files in one directory is going to cause slowdowns
of anything dealing with that directory. Sending the E-mail in batches is
the preferred way to handle the situation.
2. Once IMail hits its maximum capacity for sending E-mail, all new E-mails
will get sent directly to the queue, rather than attempting delivery. For
this, our Declude Queue (included in all the Declude products, including
the free Declude Confirm) helps out by splitting the queue into 2 separate
queues: the standard spool directory will have E-mail that IMail couldn't
deliver the first time, and a separate "overflow" queue that holds the
E-mail that hasn't been attempted yet. That way, you won't be wasting time
trying to deliver mail that won't go through, when you have fresh mail
waiting to be delivered. And, Declude Queue speeds up the delivery process
by starting new processes as needed (rather than one new process every 1/2
hour).
-Scott
---
Declude: Anti-virus, Anti-spam and Anti-hijacking solutions for
IMail. http://www.declude.com
---
[This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)]
Please visit http://www.ipswitch.com/support/mailing-lists.html
to be removed from this list.
An Archive of this list is available at:
http://www.mail-archive.com/imail_forum%40list.ipswitch.com/
Please visit the Knowledge Base for answers to frequently asked
questions: http://www.ipswitch.com/support/IMail/
