Bug #11486
Icedove autoconfig wizard gets stalled on some domains
100%
Description
At least on one email provider we’ve tested, it stays at “Trying common server names” for a loong time, while not even being connected to Tor anymore. No obviously relevant error message on stdout nor on the error console. Outside of Tails (38.7.2-1+b1 on sid, torified DNS fwiw, Torbirdy enabled but configured to enable the wizard) , the same domain works fine, and gives me secure protocols.
To be clear, the problem here is not exactly that Icedove doesn’t manage to guess (IMO it’s acceptable that our patchset breaks a small number of configurations): the problem is that the failure mode gives a pretty bad UX, especially given the “Stop” button doesn’t seem to do anything (and the console says “onStop called although there’s nothing to stop (resource:///modules/errUtils.js line 35)”).
Subtasks
Related issues
|
Related to Tails - |
Resolved | 2013-10-16 |
History
#2 Updated by intrigeri 2016-05-24 23:12:08
- related to
Feature #6154: Secure the Icedove autoconfig wizard added
#3 Updated by anonym 2016-05-25 02:28:25
- Target version set to Tails_2.5
intrigeri wrote:
> […] Outside of Tails (38.7.2-1+b1 on sid, torified DNS fwiw, Torbirdy enabled but configured to enable the wizard) , the same domain works fine, and gives me secure protocols.
Two things about your test setup:
- “torified DNS fwiw” should be irrelevant since Icedove’s MX lookup is done over HTTPS via a web service.
- With unpatched Icedove the auto configuration does not respect proxy settings, so any probing you did was made in the clear, despite TorBridy. That’s what we fixed in
Feature #6157.
> To be clear, the problem here is not exactly that Icedove doesn’t manage to guess (IMO it’s acceptable that our patchset breaks a small number of configurations): the problem is that the failure mode gives a pretty bad UX, especially given the “Stop” button doesn’t seem to do anything (and the console says “onStop called although there’s nothing to stop (resource:///modules/errUtils.js line 35)”).
Fully agreed, this needs to be investigated.
It could be a regression introduced by the SOCKS patch, somehow. when I get the time I should try with a vanilla Icedove and only apply that patch (no rebuild required — one can unpack/modify/repack some omni.ja instead). Setting an optimistic target so this stays on my radar for such an occasion.
#4 Updated by intrigeri 2016-05-25 08:50:16
> when I get the time I should try with a vanilla Icedove and only apply that patch (no rebuild required — one can unpack/modify/repack some omni.ja instead). Setting an optimistic target so this stays on my radar for such an occasion.
Cool, thank you!
#5 Updated by anonym 2016-06-09 13:23:40
- Status changed from Confirmed to In Progress
- % Done changed from 0 to 20
- QA Check set to Dev Needed
intrigeri wrote:
> At least on one email provider we’ve tested, it stays at “Trying common server names” for a loong time […]
Fixed.
> […[ the failure mode gives a pretty bad UX, especially given the “Stop” button doesn’t seem to do anything […]
Fixed.
And by “Fixed” I mean that I have commits in the secure_account_creation-38.8.0-1 branch in our icedove repo fixing them. It remains to extract them as patches to import into our Debian packaging and build new packages. Tomorrow me and u will send the patches upstream.
#6 Updated by anonym 2016-06-14 11:25:11
- Status changed from In Progress to Fix committed
- Assignee deleted (
anonym) - % Done changed from 20 to 100
- QA Check changed from Dev Needed to Pass
Solved, see Bug #11530.
#7 Updated by intrigeri 2016-07-31 10:22:53
- Deliverable for changed from SponsorS_Internal to 268
#8 Updated by intrigeri 2016-08-02 09:29:46
- Status changed from Fix committed to Resolved