This happens bacuse the message is stored with a new UID in 'Queue' folder before copied over to 'Sent' folder. I will attach a faillog with comments and a patch to compose.c with two ways to address this feature of web.de IMAP access. Both ways need an early item scan to update the cache. I hope it does not hurt. :) version1: (commented) Use function folder_item_get_msg_num_by_file from folder.c in compose.c to get the right message number. Though, that function needs to be accessible to compose.c first somehow. Not so good... version2: (used) Create a MsgInfo structure from the message ID to get the right message number. Any ideas or pointers how to fix this properly? Thanks!
Created attachment 522 [details] faillog with comments
Created attachment 523 [details] RFC: update cache to recheck message number
this is really a hack - I'm against patching that when the server gives us a wrong information.
Yes, a server feature. ;) What else I see with unpatched claws-mail is that in 'Queue' folder during send the message count changes from 0 to 1 to 0 to 1 and 0 again. Well, I will see what I find. Right now is just curing symptoms afais.
This thread on the mailing list is about problems with web.de's IMAP too: http://lists.sunsite.dk/cgi-bin/ezmlm-cgi?28:mss:10080:200711:fkdkafagdfppaacmbonp To make it short, the workaround the poster used is to have a local Queue folder instead of using the IMAP's queue folder.
Mhh, the server really returns a wrong message number. Checked with folder_item_add_msg, folder_item_scan, read msgnum -> differ. If there was a solution it would be to replace APPEND. There is a tempfile created. Could not that copied or stored instead? Or is there no other way than APPEND? I wonder how other mail clients handle this. However, since I have that hack I am fine. ;)
Just wanted to close this as WORKSFORME with 3.7.10cvs18 without my hack.