Open
Bug 417976
Opened 17 years ago
Updated 2 years ago
Make mail.auth_login a per-server based preference and change IMAP login behavior, because TB trusts capabilities reported by servers too much; they can advertise authentication capabilities they do not have
Categories
(MailNews Core :: Networking, defect)
MailNews Core
Networking
Tracking
(Not tracked)
UNCONFIRMED
People
(Reporter: petri, Unassigned)
References
()
Details
(Keywords: imap-interop)
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; sv-SE; rv:1.8.1.12) Gecko/20080201 Firefox/2.0.0.12 Build Identifier: version 2.0.0.9 (20071031) Some e-mail (POP/IMAP, possibly SMTP) servers don't like the way Thunderbird authenticates. Several sources on the net refer to how setting mail.auth_login and mail.server.default.auth_login to false enables users to connect to these servers. It seems TB trusts the capabilities reported by the servers too much; they advertise authentication capabilities they do not really have. In Sweden, at least Glocalnet and Bredbandsbolaget use servers that require users to manually set the auth_login settings. A net search revealed an Argentinian ISP (Fibertel) which also needs these settings. As plain-text auth seems to work in all cases, I think the best solution would be to default to plain-text authentication with the login command, reserving the option to use auth plain for those who explicitly want Base64 authentication. This would simplify for the home user, not having to search after workarounds. However bug 417957 must be solved before the change can be put in production releases. Reproducible: Always Steps to Reproduce: 1. Use a particular ISP:s mail server (Glocalnet, Bredbandsbolaget, Fibertel etc) Actual Results: The settings mail.auth_login and mail.server.default.auth_login are true. The connection either hangs (Fibertel) or the client can't login (Glocalnet, BBB) with a conversation with the server similar to: * OK IMAP4 server ready 1 capability * CAPABILITY IMAP4 IMAP4rev1 UIDPLUS IDLE LOGIN-REFERRALS NAMESPACE QUOTA CHILDREN AUTH=PLAIN 1 OK capabilities listed 2 authenticate plain + go ahead (Base64 encoded user/pass) * BYE disconnecting 2 NO proxy authentication failed Or similar to: +OK pop.fibertel.com.ar -- Server POP (Fibertel - Argentina) (mta01) CAPA +OK list follows TOP PIPELINING UIDL RESP-CODES AUTH-RESP-CODE USER SASL PLAIN IMPLEMENTATION MMP-6.1p0.06 Nov 11 2004 . AUTH PLAIN + (Base64 encoded user/pass) [it hangs here, nothing more happens after this step] Expected Results: The settings mail.auth_login and mail.server.default.auth_login would be false. A conversation similar to this: * OK IMAP4 server ready 1 capability * CAPABILITY IMAP4 IMAP4rev1 UIDPLUS IDLE LOGIN-REFERRALS NAMESPACE QUOTA CHILDREN AUTH=CRAM-MD5 AUTH=PLAIN 1 OK capabilities listed 2 login "user" "pass" 2 OK login successful 3 namespace It seems as if at least Apple Mail, Outlook Express and Evolution authenticate without the Base64-encoded login information, ie., using the scheme described in Expected results. The first two I have tested myself, the third was reported in a Mozillazine forum post (see refs). While the current scheme obscures the password for people quickly skimming the traffic between the computer and the server, Base64 does not offer any real security as it is so easily reversed. Also, since other very common e-mail clients use the scheme I propose as default, it would seem to the user that they work but not Thunderbird. The thought to check for workarounds would probably not be on most home users' minds. I don't think a position that single users should petition their ISPs to change mail servers used by thousands of customers is viable. NB: Personally, I haven't had issues with SMTP but Google informs me that others might have, like users of Web Panache (unknown). In these cases, too, the problem was solved by setting the auth_login settings to false. References: http://www.magnuswedberg.com/index.php?doc=Bredbandsbolaget_vs_Thunderbird http://forums.mozillazine.org/viewtopic.php?t=214380&postdays=0&postorder=asc&postsperpage=15&start=45 http://www.webpan.com/customers/Email/SMTP_Authentication_Netscape_Communicator.htm (problem seems to apply to sending e-mail as well) and many, many others - see Google search
Reporter | ||
Comment 1•17 years ago
|
||
This seems related to bug 231303. Seems like in the Swedish ISPs' case it is due to the interaction between varying versions of Critical Path and various proxy servers. It seems like a possible solution would be to change the meaning of mail.auth_login to "use auth plain/login?" instead of "use auth commands?" as it is now. Then the login code for POP and IMAP could perhaps be changed into: 1. Send CAPA(BILITY) 2. If secure login requested in acct config, check whether server supports the relevant AUTH commands and if so, go for it 3. Else if mail.auth_login is true, check whether server supports AUTH LOGIN or AUTH PLAIN and then do whatever it supports 4. Else do plaintext login
Component: General → MailNews: Networking
Product: Thunderbird → Core
Summary: Change default settings of mail.auth_login and mail.server.default.auth_login to false → Change default settings of mail.auth_login to false and change POP/IMAP login behavior
Reporter | ||
Updated•17 years ago
|
OS: Windows XP → All
Hardware: PC → All
Updated•17 years ago
|
QA Contact: general → mailnews.networking
Reporter | ||
Comment 2•17 years ago
|
||
Apparently SASL login should not be replaced by plain login for IMAP as per the IMAP RFC: "The LOGIN command SHOULD NOT be used except as a last resort, and it is recommended that client implementations have a means to disable any automatic use of the LOGIN command." Instead, a checkbox could be added for POP3/IMAP servers in the Account Configuration dialog "Disable SASL login", which is greyed out and unchecked if secure login is requested. Also the pref mail.auth_login should be changed into a per-server pref mail.server.(number or "default").auth_login pref, which then the POP3 and IMAP code checks for as per: 1. Send CAPA(BILITY) 2. If secure login requested in acct config, check whether server supports the relevant AUTH commands and if so, go for it 3. Else if mail.server.number.auth_plain is true OR (not set AND mail.server.default.auth_plain is true), check whether server supports AUTH LOGIN or AUTH PLAIN and then do whatever it supports 4. Else do plaintext login Then mail.server.*.auth_plain could mean "use auth plain/login?" and mail.server.default.auth_plain could be set to true. Changing mail.*.auth_plain to mean "use auth plain/login?" instead of meaning "use auth commands at all?" also resolves a potential case in the IMAP code when a server requires secure login and mail.*.auth_plain is set to false. In that case, the server would never be logged in to. Changing mail.auth_plain to a per-server pref solves a potential bug when one server requires SASL login, and another can't handle SASL. In that case, the current code would make this scenario require the use of two different profiles with different configuration for each server.
Severity: enhancement → minor
Keywords: interop
Reporter | ||
Updated•16 years ago
|
Summary: Change default settings of mail.auth_login to false and change POP/IMAP login behavior → Make mail.auth_login a per-server based preference and change IMAP login behavior
Assignee | ||
Updated•16 years ago
|
Product: Core → MailNews Core
Updated•8 years ago
|
Summary: Make mail.auth_login a per-server based preference and change IMAP login behavior → Make mail.auth_login a per-server based preference and change IMAP login behavior, because TB trusts capabilities reported by servers too much; they can advertise authentication capabilities they do not have
Updated•2 years ago
|
Severity: minor → S4
You need to log in
before you can comment on or make changes to this bug.
Description
•