Tails

#1 Updated by intrigeri 2018-09-14 11:27:17

• Assignee changed from anonym to lamby
• Target version changed from Tails_3.11 to 2019

(As part of Feature #6156.)

#2 Updated by lamby 2018-09-14 13:48:55

• Assignee changed from lamby to intrigeri

Did we discuss this? I don’t recall doing so, thus just wondering if it’s a mistake to assign it over to me specifically? (If it’s “to be discussed” feel free to assign back - I note the “2019” target.)

#3 Updated by intrigeri 2018-09-14 14:05:48

• Assignee changed from intrigeri to lamby

(To be discussed, like the parent ticket :)

#4 Updated by anonym 2018-11-22 16:21:02

• Description updated

#5 Updated by lamby 2019-01-04 09:46:32

• Assignee deleted (lamby)

Unassigning as-per IRL discussion at FT sprint

#6 Updated by anonym 2019-02-15 11:57:45

• Assignee set to intrigeri
• QA Check set to Info Needed

I cannot reproduce this with the Thunderbird as of Tails 3.12.1: I get 587/STARTTLS. Of course, now boum.org’s mail is handled by autistici.org… is this a new server so a server-side “fix” is a possibility? ingrigeri, I guess you might now most about this (?).

> I did not check how earlier versions (until Tails 3.8 inclusive) behave. If they behave differently, then maybe the version of the patch set that was heavily reworked for Thunderbird 60 has a regression.

I couldn’t reproduce in Tails 3.7 with Thunderbird 52.7.0 either.

BTW, the patch update for version 60 wasn’t was only “heavy” in the sense that it had to adapt vs significant upstream plumbing changes (paths moving and similar) but all logic in our patches is completely identical.

#7 Updated by intrigeri 2019-02-15 13:16:35

• Assignee changed from intrigeri to anonym
• QA Check changed from Info Needed to Dev Needed

> is this a new server so a server-side “fix” is a possibility?

I don’t see what can possibly have been “fixed” server side (what was broken?): both advertised ports worked fine back then.

> I couldn’t reproduce in Tails 3.7 with Thunderbird 52.7.0 either.

I would try to reproduce in 3.9, i.e. something closer to where I’ve seen the bug: if you can reproduce it there, but not in 3.12.1, then you’re sure the bug was in Thunderbird and has been fixed.

#8 Updated by anonym 2019-02-15 14:12:04

• Status changed from Confirmed to Rejected
• Assignee deleted (anonym)
• QA Check deleted (Dev Needed)

intrigeri wrote:
> > is this a new server so a server-side “fix” is a possibility?
>
> I don’t see what can possibly have been “fixed” server side (what was broken?): both advertised ports worked fine back then.

What I meant with “fix” was something changing on the server side making the client take another code path (assuming there is one code path where this issue arises and one where it doesn’t). This code is so complex and spaghetti like that I wouldn’t rule this scenario out.

> > I couldn’t reproduce in Tails 3.7 with Thunderbird 52.7.0 either.
>
> I would try to reproduce in 3.9, i.e. something closer to where I’ve seen the bug: if you can reproduce it there, but not in 3.12.1, then you’re sure the bug was in Thunderbird and has been fixed.

I cannot reproduce in Tails 3.9 with Thunderbird 60.0.

---

My best guess about what happened is: you got an (selectively) unreliable Tor circuit to boum.org that first failed the ISP fetch so Thunderbird fell back to port/protocol guessing. Then the scans on 587/STARTTLS and 465/SSL failed because of the unreliable circuit, but 25/STARTTLS was lucky and succeeded and thus became the best option found (that still respects of “SSL only” requirement).

IMHO this explanation is plausible enough to reject this ticket, especially when combined with the fact that we cannot reproduce. @intrigeri, please reopen if you don’t think it is good enough.