14.82 KB, image/png
15.71 KB, image/png
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.
Created attachment 132689 [details] 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.
Created attachment 132690 [details] 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.
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
Maybe related to bug 219840.
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?
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).
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!