User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/43.0.2357.125 Safari/537.36 Steps to reproduce: I used thunderbird 38.0.1 to send an email through an exchange server (STARTTLS, NTLM). Actual results: I get "Login to server XXXX failed.", and the email is not sent. Expected results: The email should have been sent without the popup window. This happens on Linux with the Arch repo version and the official mozilla build as well. I am using nss 3.19.1-1 from the Arch repo. FYI, when downgrading to 31.7.0-1 (from Arch repo, official not tested) it works.

Does it work if you set network.auth.force-generic-ntlm-v1 true (under Prefernces | Advanced | General | Config Editor)

Using network.auth.force-generic-ntlm-v1 true works! Thank you Magnus!

I've received multiple reports of this issue from ExQuilla users as well, and the fix in comment 1 fixed it for at least one. I think we should keep this bug open to consider whether we need a fix in Thunderbird (such as setting that preference by default). Not saying we should, just want to ask the question.

Yes it's a tricky question. Basically NTLMv1 is insecure. NTLMv2 was implemented in bug 423758, and v1 disabled. Perhaps Andrew has some input?

At least for ExQuilla, NTLM is being used over SSL. Many users are actually using Basic authentication which is even less secure when sent open, but is in fact OK when over SSL. So I think that the issue is NTLM in combination with SSL.

What this preference does is change the from sending an NTLMv2 response to sending the older NTLM response. Both are a material improvement over basic authentication, because both are a challenge-response authentication scheme. I know NTLM has a bad reputation, but it remains far superior to basic (plaintext) authentication and is quite reasonable over SSL. To further understand why the new NTLMv2 implementation causes a regression, the first step would be to take a PCAP network trace (eg wireshark) of the failing operation in a test domain with: - SSL (and supply the SSL private key) and - without SSL. and if possible, the same two things on Windows where SSPI is in use. I'm particularly interested if this works without SSL, as that might imply that Extended Protection (bug 630315) might need to be implemented.

I don't actually experience this myself, I only have 3 customers who have hit it (and 2 of the 3 have tried the preference workaround and confirms that it works). At least one mentioned they were using Exchange Server 2007, so I assumed that the issue was that just using really old software. These customers are using Exchange Web Services, which is over https:// So I really don't have a direct way to do the test that you are requesting. My comparison to Basic is just mentioning that the security gain from this is not really useful when the connection is over SSL, as it is in my Exchange Web Services application (over https). But back to normal email, forget Basic, many sites use Plaintext over SSL connections, which even makes Basic look good! I am assuming that for whatever reason, the sites that are failing do not support NTLMv2 responses. Is there any reason to suspect that something else may be going on? Andrew, is there any way easy way that we could make the preference work only when the connection type is SSL? That would solve my problem sufficiently that I might recommend setting the preference by default in ExQuilla. As to other possible fixes, I don't think that the correct thing to do is to by default set this preference by default in Thunderbird, or even in ExQuilla, if it applies to all connection types. If we did a workaround at all, it would be some sort of prompt when a problem was detected. A more complex workaround might be I suppose to detect that failed connection over NTLMv2, and offer NTLMv1 when the connection is otherwise secure (SSL). But that is more code than I am willing to write (and I have done necko code changes in the past in support of NTLM issues).

I should be able to get logs for a system where it fails for NTML v2 without SSL. Would that be useful? SSL isn't available for the server so I can't check working NTML+SSL to compare with.

Doesn't that support request (and our general understanding of this bug) say that esr31 is not affected?

Our university's Thunderbird users have been prevented from sending mail through our central Exchange 2010 server since upgrading to Thunderbird 38.0.1. Thanks a lot :-( Magnus Melin's Comment 1 workaround fixes the problem: network.auth.force-generic-ntlm-v1=true We simply can't explain to all our hundreds of trusty Thunderbird users that they have to fix this undocumented "feature" in Thunderbird! IMHO, it's urgent to revert to NTLM being the default! If people really need NTLMv2 it should be made a separate Authentication Method under the SMTP server menu, alongside with the old NTLM method.

(In reply to Ole Holm Nielsen from comment #10) > Our university's Thunderbird users have been prevented from sending mail > through our central Exchange 2010 server since upgrading to Thunderbird > 38.0.1. Thanks a lot :-( > Ole, would it be possible for a Thunderbird developer to be given a temporary account on that server so that we could test this?

(In reply to Kent James (:rkent) from comment #11) > (In reply to Ole Holm Nielsen from comment #10) > > Our university's Thunderbird users have been prevented from sending mail > > through our central Exchange 2010 server since upgrading to Thunderbird > > 38.0.1. Thanks a lot :-( > > > > Ole, would it be possible for a Thunderbird developer to be given a > temporary account on that server so that we could test this? I'm at a university department, so I'll forward your request to our central IT Service people. But probably any MS Exchange 2010 server would do. FYI, our SMTP AUTH server uses either SSL or STARTTLS.

(In reply to Kent James (:rkent) from comment #11) > (In reply to Ole Holm Nielsen from comment #10) > > Our university's Thunderbird users have been prevented from sending mail > > through our central Exchange 2010 server since upgrading to Thunderbird > > 38.0.1. Thanks a lot :-( > > > > Ole, would it be possible for a Thunderbird developer to be given a > temporary account on that server so that we could test this? The answer from our central IT Service people is that our Exchange 2010 server uses a Loadbalancer device which apparently can't be set up for NTLMv2 at this time. So I urge the Thunderbird developers to revert to NTLM quickly. Otherwise I predict that Thunderbird users world wide (those using Exchange servers) will very soon be migrating to other mail clients.

Another confirmation of the NTLMv2 issue: My wife is a Thunderbird user too, and her organization uses an Exchange server as well. Since upgrading to Thunderbird 38.0.1 she's been unable to send any mail at all, but Magnus' workaround in Comment 1 solves the problem. Conclusion: Thunderbird 38 and Exchange server is indeed a bad cocktail.

(In reply to Ole Holm Nielsen from comment #13) > (In reply to Kent James (:rkent) from comment #11) > > (In reply to Ole Holm Nielsen from comment #10) > > > Our university's Thunderbird users have been prevented from sending mail > > > through our central Exchange 2010 server since upgrading to Thunderbird > > > 38.0.1. Thanks a lot :-( > > > > > > > Ole, would it be possible for a Thunderbird developer to be given a > > temporary account on that server so that we could test this? > > The answer from our central IT Service people is that our Exchange 2010 > server uses a Loadbalancer device which apparently can't be set up for > NTLMv2 at this time. > > So I urge the Thunderbird developers to revert to NTLM quickly. Otherwise I > predict that Thunderbird users world wide (those using Exchange servers) > will very soon be migrating to other mail clients. Can you please get us some details as to the Load balancer? I'm quite surprised to hear it doesn't support NTLMv2, as in CIFS/SMB this upgrade has been standard in Windows clients for a number of releases now. A comparison between this and what Outlook or some other Microsoft mail client does when configured in a similar way (using IMAP and SMTP, assuming that is possible) may be illuminating.

(In reply to Kent James (:rkent) from comment #7) > A more complex workaround might be I suppose to detect that failed > connection over NTLMv2, and offer NTLMv1 when the connection is otherwise > secure (SSL). But that is more code than I am willing to write (and I have > done necko code changes in the past in support of NTLM issues). This could perhaps be done during the first-time configuration, but if you do it at login time, every time, you risk bumping the bad password count each login. Sadly NTLMv2 isn't something that is negotiated (for various reasons).

I was able to test IMAP NTLM authentication on a Linux system, using both TB 31 and TB 38. Both work, for TB 38 I can clearly see in the NTLM:5 log that NTLM Type 2 response is being handled. So at this point, there are two possibilities: 1) Thunderbird SMTP authentication does not work properly with NTLM 2 responses (in which case we should probably force NTLM 1 until we resolve this). 2) Many Exchange server installations have for some reason NTLM version 1 in use. I think this is the most likely scenario. If that is the case, I don't think that we should by default force the less secure NTLM version 1 on everybody else, particularly since there is a solid workaround. We could add a release note and perhaps a support article that mentions this issue and the workaround. It would be good if I could test a failing SMTP installation, as the reports (except for ExQuilla which is https) are for smtp not imap. If anyone could provide a test account for an SMTP server that is failing without the workaround preference setting, that would be appreciated.

I'm not yet convinced that this is an NTLMv1 vs. NTLMv2 issue. I've used an MITM TLS proxy to observe the actual communication. It gave me this with TB 38: S->C 98 '220 SRV-SBS.example.local Microsoft ESMTP MAIL Service ready at Thu, 18 Jun 2015 10:44:19 +0200\r\n' C->S 23 'EHLO [ip.ip.ip.ip]\r\n' S->C 250 '250-SRV-SBS.example.local Hello [ip.ip.ip.ip]\r\n250-SIZE\r\n250-PIPELINING\r\n250-DSN\r\n250-ENHANCEDSTATUSCODES\r\n250-STARTTLS\r\n250-X-ANONYMOUSTLS\r\n250-AUTH NTLM\r\n250-X-EXPS GSSAPI NTLM\r\n250-8BITMIME\r\n250-BINARYMIME\r\n250-CHUNKING\r\n250-XEXCH50\r\n250 XRDST\r\n' C->S 10 'STARTTLS\r\n' S->C 29 '220 2.0.0 SMTP server ready\r\n' C->S 23 'EHLO [ip.ip.ip.ip]\r\n' S->C 222 '250-SRV-SBS.example.local Hello [ip.ip.ip.ip]\r\n250-SIZE\r\n250-PIPELINING\r\n250-DSN\r\n250-ENHANCEDSTATUSCODES\r\n250-AUTH NTLM LOGIN\r\n250-X-EXPS GSSAPI NTLM\r\n250-8BITMIME\r\n250-BINARYMIME\r\n250-CHUNKING\r\n250-XEXCH50\r\n250 XRDST\r\n' At this point TB 38 stops communicating with the server and the GUI is requesting a password for the account. The password is of course already known to TB. Entering it again does not help. TB 37 on the other hand goes on with NTLM authentication as expected by sending C->S 56 'AUTH NTLM XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX=\r\n' and so on. So for some reason TB 38 does not perform the NTLM authenticaton without the workaround (network.auth.force-generic-ntlm-v1=true). Lan Manager Authentication Level on the server side is set to "Send NTLMv2 response only".

My situation is different, but related: I used IMAP+STARTTLS+Kerberos/GSSAPI against an Exchange server. After the upgrade to TB 38.0.1 TB complains "The IMAP server ... does not support the selected authentication method. Of course, for me the workaround "network.auth.force-generic-ntlm-v1=true" doesn't make sense and doesn't work. So it looks something regarding authentication method detection broke.

Michael, is your issue for IMAP or SMTP?

(In reply to stackeffect from comment #19) > I'm not yet convinced that this is an NTLMv1 vs. NTLMv2 issue. > > I've used an MITM TLS proxy to observe the actual communication. It gave me > this with TB 38: Can you please try for me: - An earlier version that supported NTLM (it was blacklisted for a bit in Firefox, I'm not sure about Thunderbird) - Windows vs Linux platforms - A Microsoft client of some kind using SMTP and NTLM. Seeing the exchange in these different situations would help a lot in understanding what is going on here. The trouble I have with your suggestion is that the NTLMv1 vs NTLMv2 choice should not be visible to layers about the NTLM lib. Indeed, what is really strange is that even load balancers shouldn't break it, unless the are quite rudely intrusive. I remain rather puzzled. We made the same upgrade in Samba quite some time ago for SMB clients and had very few issues.

(In reply to Andrew Bartlett from comment #22) > Can you please try for me: > - An earlier version that supported NTLM Not sure what you mean by "earlier version". TB 37 is the earlier version working OK in this situation. > - Windows vs Linux platforms I can try that this WE. > - A Microsoft client of some kind using SMTP and NTLM. Nope. > Seeing the exchange in these different situations would help a lot in > understanding what is going on here. To make my observation more clear: TB 38 just stops the protocol. It is not sending the "AUTH NTLM" message required to initiate the authentication. Instead it is asking the user for the password although it has that same password already. The password is known to the password manager and the master password worked: all incoming mails are pulled from the server without problems (via IMAP, no NTLM involved). There is no failed authentication attempt included in this scenario. TB 38 just does not (try to) authenticate.

(In reply to Johannes from comment #23) From the log that you gave in comment 19, this issue can be tested on the client side without having any valid credentials. I just need to confirm whether the NTLM response is sent, and if not why not. What I need is a server URL to test against. If you could send me the address and port of a server that does SMTP TLS with NTLM, I could trace this out with a debugger. You could send the address to me privately if you wish using rkent@caspia.com.

(In reply to Kent James (:rkent) from comment #21) > Michael, is your issue for IMAP or SMTP? In comment #20 I only talked about an issue with IMAP. I didn't try to send anything, as I had no mails to reply to... I just tried sending an email. It doesn't work anymore. I use Port 587, StartTLS and Kerberos/GSSAPI for sending. Looking with Wireshark, the TCP connection is reset by Thunderbird at some point after the TLS handshake (I don't have an SMTP MITM proxy, so can't look inside). Our SMTP banner before StartTLS looks like this: 220 ...servername... Microsoft ESMTP MAIL Service ready at Fri, 19 Jun 2015 12:32:09 +0200 EHLO [192.168.xxx.xxx] 250-servername Hello [192.168.xxx.xxx] 250-SIZE 20971520 250-PIPELINING 250-DSN 250-ENHANCEDSTATUSCODES 250-STARTTLS 250-AUTH GSSAPI NTLM 250-8BITMIME 250-BINARYMIME 250 CHUNKING Hope this helps.

I setup a Microsoft SMTP server on one of my test servers, enabled only Integrated Windows Authentication (NTLM). Otherwise this is a default configuration of a Windows 2010 server, with no STARTTLS. I can confirm that NTLM authentication fails with network.auth.force-generic-ntlm-v1 set to the default false, and succeeds with the true, on a Thunderbird 38 build. This is a much more severe regression than I had feared, in two ways: 1) it affects Windows clients, and 2) it happens with default configuration of a Microsoft SMTP server that requires NTLM authentication. I'll post complete transaction logs in a few minutes. I'm modifying the source so that I can log the normally suppressed responses.

Turns out to be a simple issue: SMTP is limiting the length of the response to 256 characters, when the actual NTLMv2 response is closer to 400 characters. The SMTP line itself (including CRLF) can be 512 characters, so this limit is not needed: 1432 else if (m_currentAuthMethod == SMTP_AUTH_NTLM_ENABLED || 1433 m_currentAuthMethod == SMTP_AUTH_MSN_ENABLED) 1434 { 1435 MOZ_LOG(SMTPLogModule, mozilla::LogLevel::Debug, ("NTLM/MSN auth, step 2")); 1436 nsAutoCString response; 1437 rv = DoNtlmStep2(m_responseText, response); 1438 PR_snprintf(buffer, sizeof(buffer), "%.256s" CRLF, response.get()); 1439 } Increase the .256 to .510 and the authentication works.

Given the debugging, let me make sure it is clear what this bug is about. This bug is only about NTLMv2 issues in SMTP. That means that it does not cover the failed https:// logins that my ExQuilla users are seeing, nor does it cover the IMAP issues of comment 19. Not saying those are not real issues, just saying they are not this bug.

Comment on attachment 8624891 [details] [diff] [review] Allow longer length NTLMv2 response Please make that response size dynamic, or at least truly massive. All it will take is someone using a very long domain name, or us adding in Extended Protection for #630315 and we will all be back where we started.

Andrew, thanks for the feedback. Allowing a longer response makes sense, but at the moment this bug is a critical blocker for Thunderbird 38. I would appreciate your feedback on likely lengths, but I still think that we need to have this minimum fix in for Thunderbird 38.1.0 I'm not an SMTP protocol expert, but reading the specs it looks like 512 characters is a recommended line limit, so going above that is more work as we have to support a multi-line response. Or assume that we can violate the recommended 512 character limit.

Upgrading made Thunderbird stop working with Exchange (2010, IMAP) in my case, too. The suggested workaround of toggling the NTLM settings makes no difference in my case.

(In reply to dnh from comment #32) > Upgrading made Thunderbird stop working with Exchange (2010, IMAP) in my > case, too. The suggested workaround of toggling the NTLM settings makes no > difference in my case. Please file IMAP bugs under a different bug, this is getting very confusing.

(In reply to Kent James (:rkent) from comment #31) > Andrew, thanks for the feedback. Allowing a longer response makes sense, but > at the moment this bug is a critical blocker for Thunderbird 38. I would > appreciate your feedback on likely lengths, but I still think that we need > to have this minimum fix in for Thunderbird 38.1.0 Assuming a 50 char domain name, this appears at least 3 times in the packet, which will bring at least 300 bytes (and 200 bytes additional) of output, before base64 encoding. Other variables include the username (unicode, so 2x, once per packet), and the first element of the server name (likewise unicode, 2x, twice per packet). With a long username and server name, 512 / 1.33 (base64 overhead) bytes = 386 bytes still seems quite easy to reach, we need a longer buffer. > I'm not an SMTP protocol expert, but reading the specs it looks like 512 > characters is a recommended line limit, so going above that is more work as > we have to support a multi-line response. Or assume that we can violate the > recommended 512 character limit. I'm not sure on this part, sorry. Perhaps see what a Microsoft clients does with a really long domain and username (need not actually exist to see how it gets output).

Comment on attachment 8624891 [details] [diff] [review] Allow longer length NTLMv2 response >+ PR_snprintf(buffer, sizeof(buffer), "%.510s" CRLF, response.get()); Nit: sizeof(buffer) is 512 so if response's length is at least 510 then you'll chop off the LF so that the null terminator will fit. r=me with that fixed. (The original 256 appears to be an arbitrary value from the initial version of this file that was cargo-culted through to this point.)

http://hg.mozilla.org/comm-central/rev/fbb26b3fc314 I'll file a followup bug with the issue of needed longer response length.

Comment on attachment 8624891 [details] [diff] [review] Allow longer length NTLMv2 response I'll uplift this patch in a couple of days.

I can confirm this happens without SSL (in fact TB 38 is disconnecting immediately after the welcome if using SSL or after the new welcome after STARTTLS). But in any case. TB can auth to IMAP server fine using NTLM TB cannot auth to SMTP server without the workaround, and no TLS/SSL is involved. Server is no exchange, and uses SSPI on 2k12R2, so I very much doubt it cannot handle v2. I would be looking up another tree.

sorry - re-read the problem (buffer size). We see NTLM buffer sizes increase with every new version of Windows. I would allow minimum 4kb. Also I'm pretty sure SASL spec allows for longer lines.

https://hg.mozilla.org/releases/comm-aurora/rev/b9e684c286be https://hg.mozilla.org/releases/comm-beta/rev/a62f8a4e3c1e

Comment on attachment 8624891 [details] [diff] [review] Allow longer length NTLMv2 response [Approval Request Comment] This approval request is for comm-release+SEAMONKEY_2_35_RELEASE_BRANCH Regression caused by (bug #): N/A User impact if declined: SeaMonkey 2.35 cannot send email through exchange server (NTLM) Testing completed (on c-c, etc.): Thunderbird 41, 40, 39, esr38 Risk to taking this patch (and alternatives if risky): bug fix. No risk.

Thunderbird 38.1.0 does not fix the problem for me. After updating to v 38.1.0 I set the pref network.auth.force-generic-ntlm-v1 back to false, and immediately run into the problem again when sending a message: the password prompt pops up, and the password isn't accepted. There was no such problem with TB 31. This only affects SMTP, receiving mail via IMAP from the Exchange server works fine.

I've also updated to Thunderbird 38.1.0 (on Windows 7) and used the Config editor to reset the pref network.auth.force-generic-ntlm-v1 to the default value of false. I have no problems sending mail with SMTP AUTH to our Exchange 2010 server.

Comment on attachment 8624891 [details] [diff] [review] Allow longer length NTLMv2 response uplift to comm-release+SEAMONKEY_2_35_RELEASE_BRANCH CLOSED TREE http://hg.mozilla.org/releases/comm-release/rev/c8490761484d

I have installed Thunderbird 38.2.0 (Windows 10) and the network.auth.force-generic-ntlm-v1 = true work around does not seem to work. For former version of Thunderbird is WAS working for me. Anybody knows a solution?

(In reply to Birger from comment #49) > I have installed Thunderbird 38.2.0 (Windows 10) and the > network.auth.force-generic-ntlm-v1 = true > work around does not seem to work. > For former version of Thunderbird is WAS working for me. > Anybody knows a solution? Not a solution but I have tried the "network.auth.force-generic-ntlm-v1 = true" workaround with Thunderbird 38.2.0 right now and it works (I was hit by the bug earlier today). The only difference is that I am under Ubuntu 14.04.

Same story here on Mac OSX (10.9.5) with TB 38.2.0. Couldn't connect to the exchange SMTP with "network.auth.force-generic-ntlm-v1 = false", but now can when changed to true. This bug is not resolved. Here's the log without the option set to 'false': 2071745296[100341370]: SMTP auth: server caps 0x24914, pref 0xC000, failed 0x0, avail caps 0x4000 2071745296[100341370]: (GSSAPI = 0x800, CRAM = 0x2000, NTLM = 0x4000, MSN = 0x8000, PLAIN = 0x200, LOGIN = 0x100, EXTERNAL = 0x400) 2071745296[100341370]: trying auth method 0x4000 2071745296[100341370]: SMTP entering state: 16 2071745296[100341370]: SMTP AuthLoginStep1() for etienne.gaudrain@xxxxx.xx@??2 2071745296[100341370]: NTLM/MSN auth, step 1 2071745296[100341370]: Logging suppressed for this command (it probably contained authentication information) 2071745296[100341370]: SMTP entering state: 0 2071745296[100341370]: SMTP Response: 334 TlRMTVNTUAACAAAAEAAQADgAAAAFgokCf7JNpJnHhnYAAAAAAAAAANIA0gBIAAAABgGxHQAAAA9DAE8AUgBFAC0AUgBFAFMAAgAQAEMATwBSAEUALQBSAEUAUwABABIAQwBOAEMASAAwADEAVwBWAFAABAAuAGMAbwByAGUALQByAGUAcwAuAHIAbwBvAHQAYwBvAHIAZQAuAGwAbwBjAGEAbAADAEIAYwBuAGMAaAAwADEAdwB2AHAALgBjAG8AcgBlAC0AcgBlAHMALgByAG8AbwB0AGMAbwByAGUALgBsAG8AYwBhAGwABQAcAHIAbwBvAHQAYwBvAHIAZQAuAGwAbwBjAGEAbAAHAAgAnHNM/gbr0AEAAAAA 2071745296[100341370]: SMTP entering state: 18 2071745296[100341370]: SMTP Login response, code 334 2071745296[100341370]: SMTP entering state: 17 2071745296[100341370]: SMTP AuthLoginStep2 2071745296[100341370]: NTLM/MSN auth, step 2 2071745296[100341370]: Logging suppressed for this command (it probably contained authentication information) 2071745296[100341370]: SMTP entering state: 0 2071745296[100341370]: SMTP Response: 535 5.7.3 Authentication unsuccessful 2071745296[100341370]: SMTP entering state: 18 2071745296[100341370]: SMTP Login response, code 535 2071745296[100341370]: marking auth method 0x4000 failed 2071745296[100341370]: SMTP auth: server caps 0x24914, pref 0xC000, failed 0x4000, avail caps 0x0 2071745296[100341370]: (GSSAPI = 0x800, CRAM = 0x2000, NTLM = 0x4000, MSN = 0x8000, PLAIN = 0x200, LOGIN = 0x100, EXTERNAL = 0x400) 2071745296[100341370]: no auth method remaining 2071745296[100341370]: SMTP: ask user what to do (after login failed): new password, retry or cancel 2071745296[100341370]: cancel button pressed 2071745296[100341370]: SMTP Send: QUIT 2071745296[100341370]: SMTP entering state: 0 2071745296[100341370]: SMTP entering state: 0 2071745296[100341370]: SMTP Response: 221 2.0.0 Service closing transmission channel 2071745296[100341370]: SMTP entering state: 11 And here's the log with the option set to 'true': 2071745296[100341370]: SMTP auth: server caps 0x24914, pref 0xC000, failed 0x0, avail caps 0x4000 2071745296[100341370]: (GSSAPI = 0x800, CRAM = 0x2000, NTLM = 0x4000, MSN = 0x8000, PLAIN = 0x200, LOGIN = 0x100, EXTERNAL = 0x400) 2071745296[100341370]: trying auth method 0x4000 2071745296[100341370]: SMTP entering state: 16 2071745296[100341370]: SMTP AuthLoginStep1() for etienne.gaudrain@xxxxxx.xx@??2 2071745296[100341370]: NTLM/MSN auth, step 1 2071745296[100341370]: Logging suppressed for this command (it probably contained authentication information) 2071745296[100341370]: SMTP entering state: 0 2071745296[100341370]: SMTP Response: 334 TlRMTVNTUAACAAAAEAAQADgAAAAFgokCmJeEJdLQEVQAAAAAAAAAANIA0gBIAAAABgGxHQAAAA9DAE8AUgBFAC0AUgBFAFMAAgAQAEMATwBSAEUALQBSAEUAUwABABIAQwBOAEMASAAwADEAVwBWAFAABAAuAGMAbwByAGUALQByAGUAcwAuAHIAbwBvAHQAYwBvAHIAZQAuAGwAbwBjAGEAbAADAEIAYwBuAGMAaAAwADEAdwB2AHAALgBjAG8AcgBlAC0AcgBlAHMALgByAG8AbwB0AGMAbwByAGUALgBsAG8AYwBhAGwABQAcAHIAbwBvAHQAYwBvAHIAZQAuAGwAbwBjAGEAbAAHAAgArGf/cAbr0AEAAAAA 2071745296[100341370]: SMTP entering state: 18 2071745296[100341370]: SMTP Login response, code 334 2071745296[100341370]: SMTP entering state: 17 2071745296[100341370]: SMTP AuthLoginStep2 2071745296[100341370]: NTLM/MSN auth, step 2 2071745296[100341370]: Logging suppressed for this command (it probably contained authentication information) 2071745296[100341370]: SMTP entering state: 0 2071745296[100341370]: SMTP Response: 235 2.7.0 Authentication successful 2071745296[100341370]: SMTP entering state: 18 2071745296[100341370]: SMTP Login response, code 235 Also, authentication through telnet/openssl works like a charm.

(In reply to egaudrain from comment #51) > Same story here on Mac OSX (10.9.5) with TB 38.2.0. Couldn't connect to the > exchange SMTP with "network.auth.force-generic-ntlm-v1 = false", but now can > when changed to true. > > This bug is not resolved. This bug is now interpreted as dealing with the specific issue of inadequate buffer length when used with SMTP with NTLMv2 authentication. A fix was done for that which fixed a real issue that many people were having, and the bug then resolved. Any further related issues would need to be filed in a new bug. But given that, your particular issue appears to be that your network is not properly supporting NTLMv2 so that you are forced to use a fallback to the quite insecure NTLMv1. There is no reasonable way that Mozilla is going to implement automatic fallback to the insecure NTLMv1 without forcing the user to go through some manual action such as the setting of the preference. So there is no reasonable way that this is going to change in Mozilla code. You are currently successfully using the Mozilla code as it was designed to be used. But if you disagree, please file a new bug and try to make your case.

Hmm, I am having similar issue I think. I have tried the suggestion of setting the "network.auth.force-generic-ntlm-v1 = true". It did not seem to have an effect for me. My issue is perhaps different. When I try to see e-mails in the Inbox it works fine. I also have many subfolders under the Inbox (for mailing lists sorting etc). If I try to access the mail in any of the subfolders it fails and I get the 'login failed' window popping up. I activated the logging as explained here: https://wiki.mozilla.org/MailNews:Logging What I in particular noticed is that in the log I only saw references to mail01.our.host.se, while we recently changed to mail02.our.host.se for the IMAP server address. I have changed to mail02 in the account settings but based on the log output it looks like this is perhaps not applied correctly? Is this perhaps a different issue? If I look in the config editor, I see that values such as 'mail.server.server3.hostname' is set to mail01.our.host.se, while the one item 'mail.server.server3.realhostname' is set to mail02.our.host.se. So maybe this is OK. I am also using SSL and NTLM to connect to our MS Exchange server using the IMAP protocol. I am on OSX 10.10.5, running Tbird 38.4. I also see this item is marked as fixed already, so I should perhaps not report here in any case.

clearing NI for those who seem to be unresponsive. > I also see this item is marked as fixed already, so I should perhaps not report here in any case. Indeed, anyone using a current version who still sees a problem should file a new bug report