COMMAND

    IMail

SYSTEMS AFFECTED

    IMail 5.xx, 6.xx

PROBLEM

    Anthony Santen  found following.   Ipswitch blames  BOTH  NetScape
    AND Eudora for  not following RFC's,  but does nothing  to control
    the situation.   It is very  simple to deny  service to any  IMAIL
    5.xx or 6.xx server as follows.

    IMAIL allows SMTP AUTH  using various methods, including  CRAM-MD5
    and LOGIN  If a  Eudora 4.3  client attaches  to the  IMAIL server
    supporting SMTP  AUTH, it  attempts a  connection using  CRAM-MD5.
    At this  point the  mail server  locks the  internal security  dll
    (imailsec.dll)  using  'Exclusive'  mode,  thus  disallowing other
    threads to access it.  The session with Eudora 4.3 will stay in  a
    'locked' state.  Eudora  doesn't disconnect or time-out,  nor does
    Imail.  While  the lock is  in place, NO  mail client can  use the
    server for outbound mail.

    This problem  has been  confirmed to  be only  with Eudora at this
    time.  Eudora  4.3 has been  confirmed not to  show this behaviour
    on MS-EXCHANGE or Sendmail 8.10.

SOLUTION

    The only 'work  around' available at  this time is  to restart the
    IMAIL services  on the  server.   Ipswitch's 'work  around' is  to
    open the relay, disabling the SMTP AUTH in the process.

    Ipswitch  denies  that  the  problem  is  theirs,  and claims that
    'everyone else is mad but  not us'.  Several complaints  regarding
    this problem have been received on the IMAIL forum.

    Jeff Beckley  is the  lead developer  for Windows  Eudora here  at
    Qualcomm, and he's been the one who has investigated these  issues
    of SMTP authentication with IPSwitch's IMail server.  Here's  some
    details that may be helpful for IMail users.

    The problem  is with  IMail SMTP  server versions  6.02 and below.
    When the SMTP client gives the "AUTH CRAM-MD5" command, the  IMail
    server returns a challenge that is not CRLF-delimited.  Thus,  the
    SMTP client hangs waiting  for the CRLF to  signal the end of  the
    challenge.   Eudora does  indeed timeout  after a  while.   He had
    some email conversations about two months ago with the Development
    Manager for  IMail, and  he gave  me a  beta version  of the  6.03
    version of IMail, which had  the problem fixed.  Not  sure whether
    the  6.03  version  of  IMail  has  been  released yet or not, nor
    whether it is  a free upgrade  for existing 6.x  IMail users.   He
    did also  find that  the PLAIN  authentication scheme  in the 6.03
    beta versions was broken.

    He created a  workaround in Eudora  for this bug  in the 6.02  and
    below version IMail servers.  It is to tell Eudora not to use  the
    CRAM-MD5 authentication scheme, but instead use the LOGIN  method,
    which appears to work with IMail.   Eudora 4.3 users can set  that
    up by clicking on this URL:

        x-Eudora-option:SmtpAuthBanished=CRAM-MD5

    IPSwitch has a Knowledge Base article on this, which can be  found
    at

       http://support.ipswitch.com/kb/IM-20000208-DM02.htm