No, John, you do not have that all right.
If you have a message to be delivered and it has multiple addresses and one
is 'bad', IMail will use one SMTP32 process to deliver that message, sending
it to the good addresses, but not to the bad. Once the first attempt is
made, even though all deliveries were not complete, IMail will close the
SMTP32 process and re-queue the message, but now with only the 'bad' address
(all the good ones were removed because the mail was delivered). So now,
there are no SMTP32 processes running. At the Queue Timer interval, a second
attempt will be made on that message, it will fail and be re-queued again.
This will continue until the 'Max Tries' is reached, then the message will
be bounced back to the sender with info about the non-delivery to that
address.
30 is the recommended MaxQueProc. However, with enough resources, it can be
safely increased to 60 or even 100 (I use 60 on this list.ipswitch.com
machine, because it only runs our Lists).
Only if the Alias with more than 50 addresses, causes the SMTP32 process to
be left open, can one see more than a few SMTP32 processes (a send to a
large List Server can cause a lot to be opened, but again, they will close!)
at any one time. If we assume a message was sent to this 'bad' alias, every
Queue Timer interval, COULD (but not necessarly does!) start an new SMTP32
to deliver that message, so you could get up to 20 (using the default Max
Tries) hung SMTP32 processes. You would still have 10 left and normal email
operations would still appear to be workking. If several messages caused
this problem and you reached the MaxQueProc, IMail now has no resources to
deliver a message, so it will, in effect, stop all delivery of mail. This is
EXTREEEEMLY rare, but not impossible!! KILL the SMTP32 processes and IMail
will be back to normal (restart the computer, will do the same).
Normal email delivery (not Aliases of the List type) have never been known
to cause this trouble. So there is no need to worry about it (that I know
of!! and I have been Postmaster and imtimately observed IMail operations for
over 3 years).
Queue Timer times Tries does equal the longest time mail can be 'held' in
the queue, before mail is 'bounced' back to the sender.
Daniel Donnelly
Ipswitch Technical Support
________________________________________________________
See our Knowledge Base at http://support.ipswitch.com/kb
----- Original Message -----
From: "John Morrison" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, May 09, 2000 6:17 PM
Subject: RE: [IMail Forum] BIG Problem/Dissatisfied Customer
> so I have this strait..
>
> These settings will all affect delivery efficiency.
> Redeliver attempts = 20
> queue timer = 30
> MaxQueProc = 30
> total time to expire = 10 hours or 600 minutes 20 x 30
>
> now you say the each smtp32 process one queue.
>
> with the defaults in mind
> lets say I have 5 bad external delivery attempts per hour and these will
> remain persistent for the full 20 attempts.
> within 6 hours all 30 smtp32 process are now in use...
>
> do I have to wait the 4 hours before it will send another message????
>
> so in this case
> if I can figure my number of average number or persistent delivery errors
> that remain until time out I can adjust my qtimer and redeliver attempts
as
> well as my process accordingly to compensate for peak mail performance.
>
> say from my example I increase my processor threads to 55.
> now I have enough processes to compensate for my average delivery errors.
> which leaves me for 5 free queues in the tenth hour.
>
> well now lets compensate our delivery attempts to 15 and send them every
20
> min, this also calculates the amount of time to process an undeliverable
> email.
> 15(attempts) * 20(a max period in min) = 300(max queue life in min or 5
> hours)
>
> now lets see when my queues will be fully utilized because of errors.
> 55 (SMTP queues at a time) / 5 (average errors per hour) = 11 (hours
before
> no more processing can occur)
>
> so after the first 5 hours w have only 25 queues in process.
> 55(allowed) - 25(in use due to errors) = 30 (ready and waiting)
> errors should never halt your service.
>
> How many recommended queues should I have available. providing I don't run
> out of processor power dealing with my errors.
>
>
>
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Daniel Donnelly
> Sent: Tuesday, May 09, 2000 1:02 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [IMail Forum] BIG Problem/Dissatisfied Customer
>
>
> Frank,
>
> Mentioning SMTP32 processes and Lists (.lst files) together, immediately
> brings to mind known difficulties with Aliases of the List type, that have
> too many (more than 50) email addresses or have incomplete addresses. An
> Alias that calls other aliases, that cause the 50 value to be exceeded,
> could also cause this problem. Please check ALL the Aliases in all the
> domains, to see which ones might cause this.
>
> The .lst files in the Queue are a clue to which aliases are the likely
> cause. If you do a 'Send One' and the SMTP32 task used for that delivery,
> does not close after some time, that message is the 'cause' of your
trouble.
>
> Setting the MaxQueProc to a different value, will only change the duration
> of your server working correctly after a restart, i.e. if set to 10, it
> might take 5 hours before you reach 10 open SMTP32 processes, if set to
30,
> maybe 15 hours (Example times!). Of course, if there is no mail in the
queue
> that causes this, then the time could be MUCH greater. SMPT 'Number of
> tries' has an effect, too. If set low, then no more that that number of
> attempts will be made to deliver the 'problem' message, so there cannot be
> more than this number of 'hung' SMTP32 processes.
>
> Daniel Donnelly
> Ipswitch Technical Support
> ________________________________________________________
> See our Knowledge Base at http://support.ipswitch.com/kb
>
> ----- Original Message -----
> From: "Frank Tanner" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Tuesday, May 09, 2000 3:07 PM
> Subject: RE: [IMail Forum] BIG Problem/Dissatisfied Customer
>
>
> > Again, I will re-iterate.....It is not the machine. However, it COULD
be
> > the number of SMTP threads causing it. The CPU Utilization ONLY goes
that
> > high when iMail is running.
> >
> > I can completely shut down iMail and run other types of apps on the
> server,
> > and they run just fine w/o eating the CPU cycles.
> >
> > I have set the number of SMTP threads to 10, 15, and 30 in the registry.
> I
> > get pretty much the same results all the way across the board. It seems
> > like the more threads I use the more the CPU gets used, which stands to
> > reason.
> >
> > -----Original Message-----
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED]]On Behalf Of
> > [EMAIL PROTECTED]
> > Sent: Friday, July 10, 2893 4:44 PM
> > To: [EMAIL PROTECTED]
> > Subject: RE: [IMail Forum] BIG Problem/Dissatisfied Customer
> >
> >
> > > Sometimes up to four hours.
> >
> > Given that your CPU utilization is around 75%, it sounds like you may
have
> > your maximum # of SMTP threads being used, and when new E-mail comes in,
> it
> > can't be sent out right away, so it has to wait another 10 minutes (or
> > whatever it is configured to) before being sent again. It make take a
> > number of "bumps" before it finally finds a free thread.
> >
> > Of course, that would raise the question as to why you have 75% CPU
usage.
> > That I can't answer. You might want to try making a backup, and running
> it
> > on a test machine to see if the CPU usage is so high. It may be an
issue
> > with the machine.
> >
> > > There was nothing I could find in the logs as to why they were
> > > being delayed.
> >
> > There has to be *some* information there. If it says that it receives
the
> > mail at 03:23:10, and sends it at 03:23:15, and the user complains that
it
> > takes 4 hours to get it, it's time to have a little chat with your user.
> > Logs never lie, only people do. :)
> >
> > Seriously, though, the logs should show the time the E-mail came in and
> the
> > time it finally left, plus any attempts in between. If it just shows it
> > coming it at, say, 03:23:10 and the next entry is at 07:04:20, that too
> > tells you a lot.
> > -Scott
> > Please visit http://www.ipswitch.com/support/mailing-lists.html
> > to be removed from this list.
> >
> > Please visit http://www.ipswitch.com/support/mailing-lists.html
> > to be removed from this list.
> >
>
> Please visit http://www.ipswitch.com/support/mailing-lists.html
> to be removed from this list.
>
>
> ___________________________________________________
> ITtoolbox: Portals for IT Doers and Decision-Makers
> http://www.ITtoolbox.com
> Please visit http://www.ipswitch.com/support/mailing-lists.html
> to be removed from this list.
>
Please visit http://www.ipswitch.com/support/mailing-lists.html
to be removed from this list.
