Icedove autoconfiguration is broken for ISPs serving a OAuth config

So Thunderbird support the OAuth instead of e.g. the usual “Normal password” authentication method, and it may be selected when fetching a config from the ISP or Mozilla database. In this case, Icedove will open its “bundled” browser in a new window with the OAuth login page. The requires enabling both cookies and JavaScript for the browser component in Icedove, which I believe we disable for very good reasons.

So when a config where OAuth is used is selected, autoconfig is broken in Tails’ Icedove, and it will be very messy UX-wise for users.

Crappy workaround: when the option is presented, click “Manual config” and then change the auth method for IMAP/POP and SMTP to “Normal password”. The problem is that users essentially will have to know if OAuth is gonna be selected before hand.

I crawled autoconfig.thunderbird.net to see how many mail providers have OAuth, and luckily it’s not many:

mail.ru
list.ru
jazztel.es
inbox.ru
googlemail.com
google.com
gmail.com
corp.mail.ru
bk.ru
jazztel.es
googlemail.com
google.com
gmail.com

However, some of these are very popular, e.g. the google ones and mail.ru.

Possible short-term fix: bundle valid configurations (on “disk”) for those the most popular ones at least.

Possible long-term fix: introduce a new pref (e.g. mailnews.auto_config.oauth.enabled) so OAuth configurations can be rejected. Often OAuth is the only config presented (e.g. for gmail no “Normal Password” alternative is presented) which means that autoconfiguration will have to fallback to guessing, but that’s fine. This requires more upstream Icedove work…

Feature Branch: feature/11714-icedove-45.2.0-1

Related issues

• Related to #11798 (closed)
• Blocks #6156

Original created by @anonym on 11536 (Redmine)