Ça c'est du rapport ! Merci.
Post by BasilePour information, j'ai le même problème avec un vieille version de
Communigate (3.5).
Aprés quelques investigations (debug), il semble que cela vienne de
l'interprétation de la réponse du serveur à la commande UID FETCH
(Voir fichier join), notament le UID 2979 à la fin.
La réponse du serveur semble être conforme au RFC 2060.
Dans IMAPConnection_extractResult (pour query='BODY'),
self._parseIMAPMessage (result) retourne ['body', 'uid', 2979,...].
Du coup, IMAPConnection.getMessageStructure retourne... 'uid'! C'est
cette chaine qui est passée comme paramètre structure_info à la
méthode MailMessage.loadMessage (au lieu d'une liste?).
loadMessage utilise structure_info[0] et structure_info[1] pour
generer le header content_type (j'ai content_type= u/i;
charset="ISO8859-15").
Bon, ok, c'est pas forcément trés clair, mais j'espère que ça pourra
aider... Contactez moi si vous voulez plus de détails!
Basile
* OK CommuniGate Pro IMAP Server 3.5b7 at xxxx ready
BJEM0 CAPABILITY
* CAPABILITY IMAP4 IMAP4REV1 ACL NAMESPACE UIDPLUS IDLE LITERAL+
QUOTA STARTTLS ID MULTIAPPEND AUTH=LOGIN AUTH=PLAIN AUTH=CRAM-MD5
AUTH=DIGEST-MD5 AUTH=NTLM
BJEM0 OK completed
BJEM1 OK completed
BJEM2 SELECT Junk
* FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
* OK [PERMANENTFLAGS (\Answered \Flagged \Deleted \Seen \Draft)]
limited
* 143 EXISTS
* 0 RECENT
* OK [UIDVALIDITY 267873078] UIDs valid
* OK [UNSEEN 1] message 1 is first unseen
BJEM2 OK [READ-WRITE] SELECT completed
BJEM3 UID FETCH 2979 (BODY)
* 129 FETCH (BODY ("text" "plain" ("charset" "us-ascii")
BJEM3 OK completed_______________________________________________