417976 - 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

Status: UNCONFIRMED

(MailNews Core :: Networking, defect)

Description

[Petri Kelottijärvi]

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

Comment 1

[Petri Kelottijärvi]

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

Comment 2

[Petri Kelottijärvi]

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.