Bug 204653

For sake of completeness, the GMX imapd seems to support the following capabilities:

- snip -
* OK GMX IMAP4 StreamProxy ready
. login [user] [passwd]
. OK [user] logged in
. capability
* CAPABILITY IMAP4 IMAP4rev1 IDLE AUTH=LOGIN AUTH=CRAM-MD5 UNSELECT LITERAL+
. OK Completed
. logout
. OK Completed
* BYE
closed
- snip -

If GMX _really_ does not support UIDPLUS, maybe we can fall back on full syncing?
I imagine other servers are also as crappy as GMX.

I don't have a GMX IMAP account to test with. Could you try the following in a telnet session (I'm asking since you already did that for CAPABILITY):
1) login to your account as you did for CAPABILITY
2) . SELECT INBOX
3) . FETCH 1 UID
4) Note down the returned UID, I'll refer to it as $uid below
5) . UID FETCH $uid FLAGS

If 5 fails then GMX truely doesn't support UIDPLUS.

OK, from my understanding, this means that UIDPLUS actually is supported, but not advertised by the server:

--- snip ---
[...]
. FETCH 1 UID
* 1 FETCH (UID 1465)
. OK Completed
. UID FETCH 1465 FLAGS
* 1 FETCH (UID 1465 FLAGS (\Seen))
. OK Completed
--- snip ---

Indeed seems very likely... So we could perhaps implement a small workaround.

Just to be extra sure, could you check it's returning the fame mail both for FETCH 1 and UID FETCH $uid ?

For that fetch the ENVELOPE in both cases instead of FLAGS.

Thanks.

using imap.gmx.fr (you can get a free account from gmx.fr) :

telnet imap.gmx.fr 143
Trying 213.165.64.41...
Connected to imap.gmx.fr.
Escape character is '^]'.
l* OK GMX IMAP4 StreamProxy ready
a001 login [login] [pass]
a001 OK 54663050 logged in

a002 capability
* CAPABILITY IMAP4 IMAP4rev1 IDLE AUTH=LOGIN AUTH=CRAM-MD5 UNSELECT LITERAL+
a002 OK Completed

a003 select INBOX
* FLAGS (\Answered \Flagged \Draft \Deleted \Seen)
* OK [PERMANENTFLAGS (\Answered \Flagged \Draft \Deleted \Seen)]
* 4 EXISTS
* 2 RECENT
* OK [UNSEEN 3]
* OK [UIDVALIDITY 1237467522]
* OK [UIDNEXT 18]
a003 OK [READ-WRITE] Completed

a004 FETCH 1 UID
* 1 FETCH (UID 14)
a004 OK Completed

a005 UID FETCH 14 FLAGS
* 1 FETCH (UID 14 FLAGS (\Seen))
a005 OK Completed

a008 UID FETCH 14 ENVELOPE
* 1 FETCH (UID 14 ENVELOPE ("Tue, 11 Aug 2009 17:31:35 +0200 (CEST)" "La =?ISO-8859-1?Q?cl=E9_d'une_organisation_=E0_succ=E8s?=" (("GMX Update" NIL "update" "gmx-mailings.com")) (("GMX Update" NIL "update" "gmx-mailings.com")) (("GMX Update" NIL "update" "gmx-mailings.com")) ((NIL NIL "[login]" "gmx.fr")) NIL NIL NIL "<20090811153135.6FF01220B9C9@newsletter02.web.de>"))
a008 OK Completed

a009 FETCH 1 ENVELOPE
* 1 FETCH (UID 14 ENVELOPE ("Tue, 11 Aug 2009 17:31:35 +0200 (CEST)" "La =?ISO-8859-1?Q?cl=E9_d'une_organisation_=E0_succ=E8s?=" (("GMX Update" NIL "update" "gmx-mailings.com")) (("GMX Update" NIL "update" "gmx-mailings.com")) (("GMX Update" NIL "update" "gmx-mailings.com")) ((NIL NIL "[login]" "gmx.fr")) NIL NIL NIL "<20090811153135.6FF01220B9C9@newsletter02.web.de>"))

Don't you think it is a bit strange to rely on an extension of the IMAP protocol, rather than just considering it as an optional thing?

SVN commit 1031566 by ervin:

Also catch the server greeting in the session so that we can check it
later. Useful for some server detection.

CCBUG: 204653


 M  +18 -1     session.cpp  
 M  +3 -0      session.h  
 M  +1 -0      session_p.h  
 M  +2 -0      tests/testimapserver.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1031566

SVN commit 1031567 by ervin:

If the server claims to be GMX ignore the UIDPLUS capability (just like
for GMail) as it doesn't report it but apparently implements it.

BUG: 204653


 M  +5 -1      imapaccount.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1031567