Some more background information:
I began searching for this problem a bit further, and many people which
had this problem in previous versions of Thunderbird (note: previous
versions) received various advices ranging from deleting messages that
where already received by the mail client through the webmail access,
to disabling the firewall being used.
So I went ahead to deleting the past emails received, with no good
results.
Then I decided to try the firewall approach, but instead of disabling
it, I decided to leave it be and just study what the firewall which I
use (Iptables) could possibly be doing.
I have the Iptables input chain policy set to drop packets unless
the packet matches the rules I made, provided that the target
through which it jumps to isn't also a terminative and denying one to
drop or reject the packet, it should not be dropped nor
rejected.
It's important to note that I don't have terminative and denying targets
for input packets which are transfered through TCP or UDP, just for ICMP
types (based on the IETF recommendations for ICMP packet
filtering[1][2], as my computer is in the recipient of the packet
when it's the passive victim, or the sender of the packet when it's
the active victim). Except, of course, a very first rule in the input
chain that terminatively accepts all non-ICMP packets that are
associated with an outgoing connection (that is, the output, whose
policy is to accept packets).
I rarely use the non-terminative logging target, except for logging
denial of service attacks (either if I'm a passive victim or an active
victim) or for testing purposes like this situation right now.
So I went ahead and appended to the input chain a rule to the
non-terminative log target which logs the matches to "/var/log/syslog"
with a user supplied prefix like "[IPTABLES] INPUT DROP: ".
Note for "append": As far as I know, it means "insert at the very end".
For Iptables, "the very end" would be before the chain policy would be
applied. End of note.
And so I manually configured Icedove with my IMAP login, closed
Icedove to start the test only when clicking on the "Inbox" folder of
the IMAP account (otherwise it would connect automatically to the IMAP
server).
Then I opened "/var/log/syslog", took the last timestamp since system
startup (that strange number between square brackets), opened Icedove,
forced it to connect to the IMAP server, forced it again just to make
sure that the erroneous message about unsupported authentication method
appears again, and with this simple GNU Sed and GNU Less trick:
sed --quiet '/149826\.837933/,${!d; p}' "/var/log/syslog" | less
Note (one paragraph long): This command tells GNU Sed to select from the
line that matches the 149826.837933 timestamp (the backslash/"\" is
needed before the dot because we don't want to match any single
character but a literal dot) to the last line ($), delete everything
(d) expect the selection (!) and print it (p), the brackets are just
for the "beauty" of the code as I hate unreadable code structures. End
of note.
I get regular messages (each 10 minutes or so) that look like this,
even without Icedove opened (note that the entry with the 149826.837933
timestamp was manually removed):
Dec 9 16:19:43 trisquel kernel: [149951.695846] [IPTABLES] INPUT DROP:
IN=wlan0 OUT= MAC=[Wireless interface_MAC address] SRC=[My router's
coinfiguration IP address] DST=224.0.0.1 LEN=32 TOS=0x00 PREC=0xC0
TTL=1 ID=0 DF PROTO=2
Note that in the SRC field I get the routers configuration IP address,
that is the IP address I generally use to access the router's
configuration, and the DST field is a destination not yet know by me,
unless it's a mask of some sort. So I'm thinking that this log isn't
related to this problem at all, being just a distraction, since it's
also logged when I'm not using Icedove.
So my guess is the following: Icedove is indeed receiving
response from the IMAP server, but Icedove is unable to understand the
response correctly. Considering, of course, that the response is not
malformed, as it's well interpreted by other email clients, unless the
service provider of the IMAP server really messed up with something on
his end, which is, as noted, unlikely.
REFERENCES
[1] https://tools.ietf.org/html/draft-ietf-opsec-icmp-filtering-04
[2] Note for [1]: The draft is actually expired, but it's still a good
piece of documentation.
