> When  this  problem  was prevalent a couple of years ago, I saw many
> times  in  my Imail logs where the SMTPD has PID the "main" session,
> and  the  SMTPD  PID for the AUTH call, one SMPTD log line IIRC, had
> another  PID.

In  that  case,  I  think  you  were actually seeing *symptoms* of the
problem  itself,  rather  normal process-spawning simply *tracing* the
problem.  I  don't  have  a  5.x  machine to verify this on, but later
versions  don't behave that way in the first place. Ipswitch should've
done  their  due  diligence  in  trying  to  reproduce  such a process
snapshot, if you captured it.

> OK,  look,  SMTP AUTH works for 10's or 100's of accounts, then SMTP
> AUTH  starts  failing  for  the  all  those accounts for no apparent
> reason, so the admin restarts SMTP service, and now the accounts can
> SMTP AUTH again. I don't care WTF was on the wire. It's important to
> admit that other people can be scientific,too.

I  believe  that SMTP AUTH's functionality has a breaking point, don't
get  me  wrong!  I  know  you're  not alone in reporting that it stops
working  under untraceable circumstances. I just don't think the error
is  in  the  the  AUTH function itself, since the AUTH function*s* are
actually  no  fewer  than  three  (ODBC,  SAM,  Registry),  each  with
different  code  for actually comparing the credentials; if there's no
observed  rule  as  to  which  DB  is affected most, the problem would
logically  exist at another layer. I might guess that it begins during
the transmission of the credentials over TCP, which is to say a buffer
overflow  perhaps  triggered by a single network card issue (client or
server, and we know what happens with LinkSys, et al.) while resources
are  depleted,  which  when  combined with the AUTH hashing algorithms
makes for a leaky situation (while it might not with POP3, which calls
the  same  authorization  functions, since no additional processing of
the  creds  is  necessary there). If the problem could be triggered by
load  alone,  it  would  be pretty easy to isolate where the data gets
originally garbled, but who has the time for that besides Ipswitch? :)

-Sandy


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/

Reply via email to