Thunderbird not checking for new mail at startup on certain POP3 accounts
Categories
(Thunderbird :: Mail Window Front End, defect, P3)
Tracking
(Not tracked)
People
(Reporter: rho-bot, Unassigned)
References
Details
(Keywords: dupeme)
Attachments
(4 files, 1 obsolete file)
TB_Accounts.PNG
Just noticed Thunderbird 91.5.1 is not checking for new mail on two of my 4 accounts at startup (although configured ofc). Manual triggering sync works as intended, no failures.
Did a debug on this issue and tailored log to one affected POP3 account (see logs attached), and seems authorisation at startup is different to manual sync:
- Startup sends "SendAuth()" first, which fails
- Manual sync sends "SendCapa()" first...
Could this be introduced with this commit?
https://github.com/mozilla/releases-comm-central/commit/a5bbca06d75b859f521d2cfded067ea41219efe1#diff-fcd22bd6b267d2e8ab68625ff9eaaf521bd6fcbddb1bdd839f1a6a3c76174b1a
This default "POP3_AUTH_MECH_UNDEFINED" makes a difference:
https://github.com/mozilla/releases-comm-central/blob/a5bbca06d75b859f521d2cfded067ea41219efe1/mailnews/local/src/nsPop3Protocol.cpp#L3594
|
||
Comment 2•3 years ago
|
||
I observe the same for 91.5.0 on Xubuntu 20.04.3. Since the unattended upgrade from 78.14.0 to 91.5.0 a few days ago my primary email account is not checked at startup or the check does not find the emails present. (I suspect the latter because I did a tcpdump and found as many connects to POP3 servers as I have configured in my accounts.) If I then manually hit "Get Messages" they arrive. Other accounts are checked and their new email shows up.
If I have to speculate I would assume a timing issue where maybe the first account is attempted to check when Thunderbird has not come up fully or not loaded everything that it requires. The system runs off a SSD if that is useful information.
|
||
Comment 3•3 years ago
|
||
Thanks rho-bot for this detailed bug report. I totally believe that this can happen as we have an assortment of bugs on record around this.
- Could you describe the difference between the two accounts where it works and the two where it fails?
- Is it still not doing startup checks even after you once initiated manual check?
- Does any of these bugs match your issue (e.g. bug 1745599)?
- Does the "workaround" of bug 1745599, comment 8 solve the problem for you?
|
||
Updated•3 years ago
|
|
|
||
Comment 4•3 years ago
|
||
:rho-bot: according to bug 1752397, there is some change on the gmx side that treats empty AUTH as an invalid command. Can you please try with a 78 version? If it works on 78 but not on 91 then we can be sure it's a TB bug.
:Robert: is it also a gmx account that you see this problem?
|
|
||
Comment 6•3 years ago
|
||
(In reply to Ping Chen (:rnons) from comment #4)
:Robert: is it also a gmx account that you see this problem?
Yes, exactly.
|
||
Comment 7•3 years ago
|
||
Where (and why) is the difference between the startup POP account AUTH and the manually triggered AUTH?
Obiously 1&1 (GMX, WEB, IONOS) changed their rules. The e-mail client K9 Mail got the same problem: suddenly mail fetching was not possible anymore.
K9 reacted quickly, details here:
https://forum.k9mail.app/t/fetching-mails-from-gmx-stopped-working-certificate-error-configuration-fails-starttls-not-available/
In the Changelog of K9 you can now read: "POP3: Changed the way the list of supported authentication methods is retrieved from the server".
As a (hopefully only temporary) "workaround", it is possible to set mail.server.server1.authMethod to 2 (In my profile server1 is GMX.de).
Thereafter mail retrieval works again "as before".
|
||
Comment 10•3 years ago
|
||
Hmmm ... on my original bug submission 1745599, which was duped to here, for thunderbird was not checking for mail on 2 pop accounts- Spectrum mail and Earthlink Mindspring mail and my gmail imap account versus just pop accounts, unless I am missing something..
Which log files are you looking for ? I have Thunderbird 64 bit on Windows 10. I have a full system backup from the day before I got email checking again on startup by deleting the session.json file and the parent.lock file. Then I have a full thunderbird backup from 2 days before I made the changes. I can extract files from either.
My failure was only on startup the timed email checks always worked. Seems like if there was a certificate or other login issue, neither would work.
|
Reporter | |
Comment 11•3 years ago
|
||
|
|
Reporter | |
Comment 12•3 years ago
|
||
(In reply to Thomas D. (:thomas8) from comment #3)
Thanks rho-bot for this detailed bug report. I totally believe that this can happen as we have an assortment of bugs on record around this.
- Could you describe the difference between the two accounts where it works and the two where it fails?
See Attached image TB_Accounts.PNG
Both failing accounts are GMX.DE ones
- Is it still not doing startup checks even after you once initiated manual check?
Yes, startup bug is permanent for GMX.DE
At startup, they are not checked. Manual check and/or Scheduled check work as intended.
- Does any of these bugs match your issue (e.g. bug 1745599)?
- Does the "workaround" of bug 1745599, comment 8 solve the problem for you?
No, just checked before reporting. Deleting "session.json/xulstore.json/parent.lock" doesn't change anything.
(In reply to Robert Klemme from comment #2)
[...]
If I have to speculate I would assume a timing issue where maybe the first account is attempted to check when Thunderbird has not come up fully or not loaded everything that it requires. The system runs off a SSD if that is useful information.
I'm sure it's not timing related, in my setup of 4 accounts GMX.DE is checked as third & fourth.
(In reply to Ping Chen (:rnons) from comment #4)
:rho-bot: according to bug 1752397, there is some change on the gmx side that treats empty
AUTHas an invalid command. Can you please try with a 78 version? If it works on 78 but not on 91 then we can be sure it's a TB bug.
It started somewhen Mid Jan.2022, so it was definitely working before with TB91.
Thanks for the linked bug report, I missed that. This confirms that GMX changed their POP3 protocol.
** So it's not a general bug in TB, but some servers may not support unintended AUTH command anymore in future due to hardening. **
(In reply to C-E from comment #8)
Obiously 1&1 (GMX, WEB, IONOS) changed their rules. The e-mail client K9 Mail got the same problem: suddenly mail fetching was not possible anymore.
Yes, they just dropped the AUTH() completely by this commit
Maybe complete drop of AUTH() is not necessary, but it should definitely handle server response "-ERR" and disconnection.
|
|
Reporter | |
Comment 13•3 years ago
|
||
|
||
Comment 14•3 years ago
|
||
Hello,
sorry I'm new here just to tell you guys that GMX and the other providers 1&1, Strato, WEB, IONOS,... changed their system and checking for new mail via POP3 at startup works again.
We watched this error at the german TB Forum for several days and waited for a fix from TB or GMX. I'm using TB only with IMAP and just created an extra POP3 account to comprehend the other users - I'm only the messenger and don't understand POP3 Protocol. Anyway this is now the LOG with GMX and POP3 at startup, maybe this helps:
2022-02-02 14:24:57.129000 UTC - [Parent 11544: Main Thread]: I/POP3 [this=23ba6a6ec00] SEND: AUTH
2022-02-02 14:24:57.164000 UTC - [Parent 11544: Main Thread]: I/POP3 [this=23ba6a6ec00] Entering NET_ProcessPop3 26
2022-02-02 14:24:57.164000 UTC - [Parent 11544: Main Thread]: I/POP3 [this=23ba6a6ec00] Entering state: 3
2022-02-02 14:24:57.164000 UTC - [Parent 11544: Main Thread]: I/POP3 [this=23ba6a6ec00] RECV: -ERR 1 argument required
Again, sorry for just crashing in here without any knowledge. Thanks for your work at TB.
Greetings, dErzOnk
|
|
Reporter | |
Comment 15•3 years ago
|
||
Yes, confirmed GMX changed their interface to "not disconnect" after AUTH().
Startup check is working again.
Question left:
Is this only a temporary workaround by GMX, until the drop of AUTH() by TB is rolled out? (see 1752397)
Or will they stay on this implementation, and drop of AUTH() by TB can be skipped? (In this case we may see this upcoming again on other providers :/)
|
|
||
Comment 16•3 years ago
|
||
(In reply to rho-bot from comment #12)
(In reply to Robert Klemme from comment #2)
If I have to speculate I would assume a timing issue where maybe the first account is attempted to check when Thunderbird has not come up fully or not loaded everything that it requires. The system runs off a SSD if that is useful information.
I'm sure it's not timing related, in my setup of 4 accounts GMX.DE is checked as third & fourth.
I am not sure I understand: for me the first account is not checked but other GMX and WEB.de accounts are; so that could be related to the order and timing. Anyway, by now I think it has been established via the K9 report it is indeed related to the auth handling change.
|
|
Reporter | |
Comment 17•3 years ago
|
||
(In reply to Robert Klemme from comment #16)
I am not sure I understand: for me the first account is not checked but other GMX and WEB.de accounts are; so that could be related to the order and timing. Anyway, by now I think it has been established via the K9 report it is indeed related to the auth handling change.
Maybe your other accounts are configured for IMAP, not POP3...
Anyhow, GMX confirmed they changed POP3 interface (bug 1752397), and now (temporarily) fixed it.
|
|
||
Comment 18•3 years ago
|
||
(In reply to rho-bot from comment #17)
(In reply to Robert Klemme from comment #16)
I am not sure I understand: for me the first account is not checked but other GMX and WEB.de accounts are; so that could be related to the order and timing. Anyway, by now I think it has been established via the K9 report it is indeed related to the auth handling change.
Maybe your other accounts are configured for IMAP, not POP3...
No, first three accounts are POP3 at GMX, then there is one IMAP and one other POP3 at WEB.de. The first one is / was definitively not checked but others were.
Anyhow, GMX confirmed they changed POP3 interface (bug 1752397), and now (temporarily) fixed it.
Ah, good to know! Thx!
|
|
||
Comment 19•3 years ago
|
||
I'm duplicating this to bug 1752397, which contains fixes on TB side. You can still leave comments here.
, and now (temporarily) fixed it.
If this is the case, I don't need to uplift bug 1752397 to esr91 then. Let me know if it's still a problem, thanks.
Or will they stay on this implementation, and drop of AUTH() by TB can be skipped? (In this case we may see this upcoming again on other providers :/)
A new POP3 implementation (bug 1707548) without the initial AUTH will be enabled on TB nightly soon, and hopefully will go to this year's ESR release.
|
|
Reporter | |
Comment 20•3 years ago
|
||
Thanks for your support on this bug :) At the moment, it's solved by GMX workaround.
Regarding uplift bug 1752397 to esr91, maybe Hannah Stern can answer if GMX will agree to keep the workaround until next esr102.3 (2022-09-20)?
In any case, IMO it's good practice to drop this initial AUTH(), as it never made it into standard. Another small step to make TB even better.
Just wondering that this method worked that long without issues. But as security becomes more important nowadays, it's likely also other providers will sooner or later remove this "non-standard" behaviour.
|
||
Comment 21•3 years ago
|
||
Hi!
Even though this bug is closed now:
I'm glad this will be fixed on Thunderbird's side.
And I've clarified this, yes we can ensure that we'll not drop connections after AUTH-without-parameters for the foreseeable future. This will be at least up to the autumn Thunderbird ESR you named. We'll keep answering "-ERR" as we used to do before we introduced disconnecting, experience has shown that this is okay enough with existing clients. Answering "+OK" would mislead clients implementing draft-myers-sasl-pop3-05 into expecting additional data (authentication mechanisms, and a line with ".") before continuing.
Hope this helps!
Hannah.
Description
•