[En cours] Serveur IMAP non conforme => problèmes de suppression

lolz · Nouveau **Hors-ligne**

Bonjour,

Le serveur imap.Free.fr n'est pas conforme aux spécifications RFC 3501 (http://www.faqs.org/rfcs/rfc3501.html), ce qui pose des problèmes avec certains client mail.

Voici le resultat d'une command 'SELECT' sous telnet sur imap.Free.fr:
. select inbox
* 115 EXISTS
* 0 RECENT
* OK [UIDVALIDITY 1058272179] UID validity status
* OK [UIDNEXT 8309] Predicted next UID
* FLAGS (\Answered \Flagged \Deleted \Draft \Seen)
* OK [PERMANENTFLAGS ()] Permanent flags
. OK [READ-WRITE] SELECT completed

Le problème vient de la ligne "* OK [PERMANENTFLAGS ()] Permanent flags". D'après la RFC:

OK [PERMANENTFLAGS (<list of flags>)]
A list of message flags that the client can change
permanently. If this is missing, the client should
assume that all flags can be changed permanently.

Or comme le resultat du 'SELECT' le montre, PERMANENTFLAGS est présent ET vide. Un client mail qui implémente l'IMAP en respectant la RFC est donc dans l'impossibilité de 'flagger' les messages correctement (seen, deleted, etc.).

Le problème est particulièrement flagrant avec Opera 9 : il est impossible de supprimer des messages ou de les marquer comme lus avec ce client. Firefox ne se comporte pas correctement non plus mais c'est un peu moins évident.

Pour etre conforme à la RFC, il faudrait soit que PERMANENTFLAGS soit absent ou que la liste ne soit pas vide. J'ai cherché sur www.Free.fr comment signaler ce problème mais je n'ai rien trouvé et je ne suis pas sur que les gens de chez Free lisent ces forums. Est-ce que quelqu'un sait comment faire remonter ce genre de problèmes chez Free?

Merci d'avance.

jkirsch · Connaisseur **Hors-ligne**

lolz · Nouveau **Hors-ligne**

Le 'this' fait référence à PERMANENTFLAGS. Voici une autre citation de la RFC qui explique un peu plus comment il faut interpreter la description:

jkirsch · Connaisseur **Hors-ligne**

Même avec ta citation supplémentaire, ce n'est pas du tout ça que je comprends.
Mais bon, je peux me tromper aussi.

lolz · Nouveau **Hors-ligne**

Ca me semble pourtant évident. La RFC 3501 introduit des données qui n'existaient pas dans les implémentations précédentes.

Avant il n'y avait que FLAGS, EXISTS, and RECENT. Donc certains serveurs n'enverront que ces données. Que doit faire un client qui implémente la RFC 3501 et qui s'attend à recevoir PERMANENTFLAGS? C'est ce que spécifie la phrase "If this is missing, the client should assume that all flags can be changed permanently". C'est ce qui est dit dans ma seconde citation: un comportement par défaut a été spécifié pour combler les lacunes des versions antérieures du protocole.

Et puis bon, il faudrait accorder un peu de crédit aux auteurs de la RFC, ils ne sont pas complètement idiots non plus. Pourquoi auraient-ils pondu un protocole dans lequel:
- pas de PERMANENTFLAGS => ?
- liste vide => tous les flags peuvent être utilisés.
- liste non vide => seuls les flags spécifiés peuvent être utilisés.
Puisque si l'on considère que "If this is missing, the client should assume that all flags can be changed permanently" fait référence à la liste vide, alors rien n'a été spécifié pour l'absence de PERMANENTFLAGS...

Admettons que la phrase ci-dessous englobe à la fois "pas de PERMANENTFLAGS" et "liste vide". Le protocole devient:
- pas de PERMANENTFLAGS => tous les flags peuvent être utilisés.
- liste vide => tous les flags peuvent être utilisés.
- liste non vide => seuls les flags spécifiés peuvent être utilisés.
Bien. Et que dois-je faire si je veux qu'aucun flag ne puisse être utilisé?

Il est quand même plus cohérent d'avoir:
- pas de PERMANENTFLAGS => comportement par défaut: tous les flags peuvent être utilisés.
- liste vide => aucun flag ne peut être utilisé.
- liste non vide => seuls les flags spécifiés peuvent être utilisés.

Je ne vois pas pourquoi la RFC devraient être interprêtée autrement... Mais bon, ce n'est pas à moi à discuter de ca. Mon point est que les clients mail (Opera 9, Thunderbird & co.) ne fonctionnent pas correctement avec imap.Free.fr. Les developpeurs d'Opera prétendent que ca vient du serveur (et Opera marche d'ailleurs très bien avec d'autres serveurs). Si les admins Free pensent que leur serveur n'est pas en cause et que c'est les développeurs de clients mail qui ne savent pas lire une RFC, je les invite à argumenter directement avec des gens qui s'y connaissent mieux que moi!

lolz · Nouveau **Hors-ligne**

J'ai fait des tests avec:
- Opera 9/Linux
- Thunderbird/Linux
- Thunderbird/Windows

et j'ai plus ou moins le meme problème, mais je pose demande si je ne suis pas le seul...

Y a-t-il d'autres personnes qui, après avoir vidé la corbeille avec leur client mail, retrouve les messages sous webmail (status supprimés, mais non purgés)?