User-Agent: Mozilla/5.0 (Windows; U; Win98; de-AT; rv:1.7b) Gecko/20040314 Build Identifier: Mozilla/5.0 (Windows; U; Win98; de-AT; rv:1.7b) Gecko/20040314 Mozilla does not use the AUTH PLAIN mode as requested from SMTP server and trys a AUTH CRAM-MD5 authentification as first. If this fails then Mozilla uses AUTH PLAIN. This generates an authentication error (including an mail administrator notification warning mail) each time someone sends a message. Server logfile: Incoming SMTP Server connection from [xx.xx.xx.xx] SMTPRX-SND : 220 server.domain ESMTP Server FTGate SMTPRX-RCV: EHLO domain.de SMTPRX-SND : 250-server.domain 250-VRFY 250-EXPN 250-ETRN 250-AUTH CRAM-MD5 LOGIN PLAIN 250 Ready SMTPRX-RCV: AUTH CRAM-MD5 SMTPRX-SND : 334 PDIzMi4xMDc5MTAxMjA0QHNpbnVzLTEuc2ludXM+ SMTPRX-RCV: bmF1IGVmODNkMWY2NTU3YWE0NDVmYjBhZGViZTkzYmU1NDkx SMTPRX-SND : 535 AUTHorisation failure SMTP AUTH failure <username>, [xx.xx.xx.x] SMTPRX-RCV: AUTH PLAIN AG5hdQBmb2VwcGw= SMTPRX-SND : 235 AUTHorisation successful SMTPRX-RCV: MAIL FROM:<email@example.com> New message created [f04031215200403CF] Older versions does this correct (Mozilla 1.3.1 for example). Server logfile: Incoming SMTP Server connection from [xx.xx.xx.xx] SMTPRX-SND : 220 server.domain ESMTP Server FTGate SMTPRX-RCV: EHLO domain.de SMTPRX-SND : 250-server.domain SMTPRX-SND : 250-VRFY 250-EXPN 250-ETRN 250-AUTH CRAM-MD5 LOGIN PLAIN 250 Ready SMTPRX-RCV: AUTH PLAIN AG1pY2hhZWwua29jaABzY2h3YWNoc2lubg== SMTPRX-SND : 235 AUTHorisation successful SMTPRX-RCV: MAIL FROM:<firstname.lastname@example.org> New message created [f04031215222703D6] Reproducible: Always Steps to Reproduce: 1. Install a FTGate Office mailserver 2. Configure the server to accept messages only from authenticated sources 3. Enable detailed SMTP logging options 4. Send an message via SMTP 5. Inspect the logfile Actual Results: The mail server reports a authentication failure, and the mail administrator receives a warning notification message. Expected Results: Using the correct authentification method in the first step or give the user the possibility to configure the authentification method.
Mozilla does it in the order as requested by the mailserver (AUTH CRAM-MD5 LOGIN PLAIN). What's the use of authentication, if Mozilla would choose the most insecure method first ? Note: Mozilla 1.3.1 ignored CRAM-MD5, that's why you saw PLAIN first
Erm, not exactly in the order requested by the server, Jo. Mozilla always uses most secure first and then goes down to weaker mechanisms. In particular: CRAM-MD5, NTLM, PLAIN, LOGIN (each mechanism of course only if advertised by the server) Torsten, why do you assume a client should use PLAIN first? To my knowledge there isn't a standard for the order. If the mail server isn't capable of doing CRAM-MD5, why is it activated? Just deactivate it and you'll not get any error notification. And yes, there is a way to deactivate CRAM-MD5 (resp. all secure authentications) for broken servers. It has no UI because it shouldn't be necessary. Set a pref trySecAuth for the server (or the default for all servers) to false and we'll ignore it. But in the first line it's the servers fault and should be correct there.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → INVALID
OK, the problem is not the order of authentication. Mozilla is working fine. It has to do with the configuration of passwords inside our mailserver. If we use the passwords from the domain controller the authentication fails. The FTGate support confirmed this: --- OK, for cram-md5 to work both sides must know what the password is, but if you use NT authentication FTGate does not know what the password is, so FTGate will always fail to authenticate with cram-md5 for NT passwords, i.e. it is a limitation of cram-md5, not FTGate. ---
Yep, that's true. The drawback of CRAM-MD5 is, that the PW has to be saved unencrypted.
You need to log in before you can comment on or make changes to this bug.