Discussion:
MercuryC SMTP AUTH problem
(too old to reply)
D.-Oliver Krusch
2006-08-23 15:09:49 UTC
Permalink
Hi,

I'm running Mercury/32 v4.01b. My ISP demands SMTP AUTH before
accepting mail.

So I configured the MercuryC Module accordingly, but when I try to
send mail via my ISP's smart host I get an authentification error.

The MercuryC log shows the following:

T 20060823 164946 768 Established ESMTP connection to mail.myisp.com
T 20060823 164946 768 Begin processing job MO000002 from ***@mydomain.com
E 20060823 164948 768 Bad AUTH CRAM-MD5 response from server 212.XXX.XX.XX

Obviously there is some problem with either the ISP's server's
or MercuryC's way of handling CRAM-MD5 login.

The ISP's smart host also accepts PLAIN LOGIN, which I tried (on the
command line with telnet and Outlook Express) and which works.

According to the Mercury documentation Mercury is also able to handle
PLAIN LOGIN.

Is there a way to force MercuryC to use PLAIN LOGIN; or for that
matter another solution for my problem (aside from switching ISPs).

Regards

Oliver
Rob
2006-08-23 15:46:30 UTC
Permalink
Post by D.-Oliver Krusch
Hi,
I'm running Mercury/32 v4.01b. My ISP demands SMTP AUTH before
accepting mail.
So I configured the MercuryC Module accordingly, but when I try to
send mail via my ISP's smart host I get an authentification error.
T 20060823 164946 768 Established ESMTP connection to mail.myisp.com
T 20060823 164946 768 Begin processing job MO000002 from
server 212.XXX.XX.XX
Obviously there is some problem with either the ISP's server's
or MercuryC's way of handling CRAM-MD5 login.
The ISP's smart host also accepts PLAIN LOGIN, which I tried (on the
command line with telnet and Outlook Express) and which works.
According to the Mercury documentation Mercury is also able to handle
PLAIN LOGIN.
Is there a way to force MercuryC to use PLAIN LOGIN; or for that
matter another solution for my problem (aside from switching ISPs).
MercuryC will automatically use the strongest form of authentication
advertised by the relay server. If CRAM-MD5 is advertised, MercuryC will
use it. You cannot force MercuryC to use a specific form of
authentication.

Since you munged out the ISP's server host name and IP address, no one
can check it for you to see if it is indeed issuing an incorrect
response, or if this is a MercuryC issue.

FWIW - I remember hearing problems with some mail server's implementation
of CRAM-MD5 many months ago. I don't remember which mail server it was,
though. It is possible that your ISP is using a broken implementation of
CRAM-MD5. If their customers normally use a client that does not support
CRAM-MD5, then they may not notice the problem.
--
Rob Croson (***@arcm.com)
Member of the Pegasus Mail and Mercury/32 Beta Test Teams
Pegasus Mail and Mercury/32 Portal: http://email.arcm.com
Visit the MailWiki: http://email.arcm.com/wiki
Support Pegasus Mail: http://www.cafeshops.com/pegasusmail
D.-Oliver Krusch
2006-08-23 21:03:09 UTC
Permalink
[SNIP]

Rob> MercuryC will automatically use the strongest form of
Rob> authentication advertised by the relay server. If CRAM-MD5 is
Rob> advertised, MercuryC will use it. You cannot force MercuryC
Rob> to use a specific form of authentication.

Okay, thanks for confirming that.

Rob> Since you munged out the ISP's server host name and IP
Rob> address, no one can check it for you to see if it is indeed
Rob> issuing an incorrect response, or if this is a MercuryC
Rob> issue.

I understand that. But before disclosing the real address, I'd have to
check with the person who rented the account.

But meanwhile I tried authenticating with another CRAM-MD5 capable
smtp-relay-server (Janaserver) and also two command line
scripts. Neither was able to authenticate successfully with the smtp
server in question.

So I don't think it's a MercuryC issue, but a broken or misconfigured
cram-md5 implementation.

Rob> FWIW - I remember hearing problems with some mail server's
Rob> implementation of CRAM-MD5 many months ago. I don't remember
Rob> which mail server it was, though. It is possible that your
Rob> ISP is using a broken implementation of CRAM-MD5. If their
Rob> customers normally use a client that does not support
Rob> CRAM-MD5, then they may not notice the problem.

That's exactly what I'm thinking right now. I'll try and contact the
ISP, but I don't have much hope of getting anywhere with them.

FWIW, I tried a HELP command with the server and it answered:
214 qmail home page: http://pobox.com/~djb/qmail.html

Unfortunately I don't have a qmail server available right now to
crosscheck and see if it's a general problem or a qmail
misconfiguration.

Thanks for the fast response.

Regards

Oliver

Loading...