221303 - starttls and qmail broken since 1.4

Status: RESOLVED INVALID

(MailNews Core :: Networking: SMTP, defect)

Description

[David R]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624

I have a qmail setup where I use starttls. Since version 1.4, when sending mail,
I first get a dialog asking me to authenticate, then after a small delay I get
an error message saying "Sending of message failed. The message could not be
sent because connecting to the SMTP server failed. The server may be unavailable
or refusing SMTP connections." However, the exact same profile works under the
default mozilla 1.3 installed under RedHat 9. The server is definitely
available. I used ethereal to snoop on the conversation, and Mozilla connects to
the server, issues a "EHLO servername.com" command, then issues a "STARTTLS"
command. It then attempts to establish an SSL session but apparently fails. I'm
investigating a "man in the middle" approach to seeing what's in the SSL
communications. I can provide a dump of the appropriate packets if that would be
helpful.

Reproducible: Always

Steps to Reproduce:
1. Create a new message
2. Attempt to send


Actual Results:  
Error message: "Sending of message failed. The message could not be sent because
connecting to the SMTP server failed. The server may be unavailable or refusing
SMTP connections."

Expected Results:  
Sent the message.

Comment 1

[David R]

Attachment: What a netcat session looks like under 1.2.1 (default rh9)

This is what a netcat session looks like under 1.2.1, the default browser with
redhat 9. All server commands were manually entered by me.

Comment 2

[David R]

Attachment: what a netcat session looks like under 1.4/1.5rc1/2

This is what a netcat session looks like under 1.4 and 1.5rc1/2. I am not sure
if this is even relevant, but there is an extra "xterm" addition. Perhaps this
is a result of the fact that it was in an xterm session with netcat, or perhaps
it is the source of the bug.

Comment 3

[David R]

I'd like to add that this bug occurs on all versions I've tested since 1.4,
including 1.4, 1.5rc1 and 1.5rc2. I also wanted to clarify that the version that
WORKS isn't 1.3 but 1.2.1

Comment 4

[Christian Eyrich]

Maybe related to bug 219840.

Comment 5

[David R]

After doing some additional research, and downloading a nightly build, I found
what I think is the source of the problem. Mozilla 1.2.1 uses AUTH PLAIN as the
default AUTH mechanism. This works fine. Mozilla 1.4+ uses AUTH CRAM-MD5 by
default. For some reason my mail server is having trouble with this particular
AUTH method. Is there some option for me to tell Mozilla not to use AUTH
CRAM-MD5 by default and to use AUTH PLAIN instead?

Comment 6

[Christian Eyrich]

Hm, if this is the problem, shouldn't you have the same problems without
starttls? Or is the list of authentication mechanisms with and without
encryption different?

But yes, we have such a switch.
If you set mail.smtpserver.smtpx.trySecAuth (where smtpx is the number of the
server) to false, Mozilla won't try using CRAM-MD5.

If CRAM-MD5 is the reason it's likely that your server is broken. But I'd
nevertheless be interested in a communications log (either ethereal or
compatible or see
http://www.mozilla.org/quality/mailnews/mail-troubleshoot.html#smtp).

Comment 7

[David R]

Yeah, my mail server is broken, it seems. This is puzzling me. It most likely
needs a restart, which I'll try. Sorry for wasting anybody's time. It seemed by
all appearances a Mozilla bug, which, it turns out, it was not. Resolution
appropriately set to "INVALID".

Thanks!