Eric Demeester (Sun, 08 Feb 2015 16:19:40 +0100 - fr.comp.mail) :
La lecture de la RFC étant un peu fastidieuse, voici la liste des commandes POP échangées en TELNET entre le courriéleur et le serveur lors d'une session POP3 : (http://www.linux-france.org/article/web/egraffin/pop3.php)
Je donne quand même le lien vers la RFC 1939 traduite en français, les exemples donnés sont plus précis, même si le vocabulaire est parfois un peu indigeste :) http://abcdrfc.free.fr/rfc-vf/rfc1939.html
Eric Demeester (Sun, 08 Feb 2015 16:19:40 +0100 - fr.comp.mail) :
La lecture de la RFC étant un peu fastidieuse, voici la liste des
commandes POP échangées en TELNET entre le courriéleur et le serveur
lors d'une session POP3 :
(http://www.linux-france.org/article/web/egraffin/pop3.php)
Je donne quand même le lien vers la RFC 1939 traduite en français, les
exemples donnés sont plus précis, même si le vocabulaire est parfois un
peu indigeste :)
http://abcdrfc.free.fr/rfc-vf/rfc1939.html
Eric Demeester (Sun, 08 Feb 2015 16:19:40 +0100 - fr.comp.mail) :
La lecture de la RFC étant un peu fastidieuse, voici la liste des commandes POP échangées en TELNET entre le courriéleur et le serveur lors d'une session POP3 : (http://www.linux-france.org/article/web/egraffin/pop3.php)
Je donne quand même le lien vers la RFC 1939 traduite en français, les exemples donnés sont plus précis, même si le vocabulaire est parfois un peu indigeste :) http://abcdrfc.free.fr/rfc-vf/rfc1939.html
Erwan David
siger écrivait :
a écrit :
Le 07/02/15 09:28, siger a écrit :
Est-ce vrai que c'est le courrielleur qui marque les messages comme lu sur le serveur, en POP ?
Euh, le protocole POP3 est destiner à "fetcher" les mails distants pour les lire en local, avec possibilité de les laisser sur le serveur.
Oui (je ne sais pas ce qu'est fetcher, mais je suppose), mais en quoi ça exclue le fait de marquer comme lu ? Il peut choisir de les supprimer ou pas, avec un délais ou pas, pourquoi pas ça ?
Parceque ce n'est pas une commande du protocole et que donc on ne peux pas le demander au serveur.
-- Les simplifications c'est trop compliqué
siger <guinness@hic.invalid> écrivait :
a écrit :
Le 07/02/15 09:28, siger a écrit :
Est-ce vrai que c'est le courrielleur qui marque les messages
comme lu sur le serveur, en POP ?
Euh, le protocole POP3 est destiner à "fetcher" les mails distants
pour les lire en local, avec possibilité de les laisser sur le
serveur.
Oui (je ne sais pas ce qu'est fetcher, mais je suppose), mais en quoi
ça exclue le fait de marquer comme lu ? Il peut choisir de les
supprimer ou pas, avec un délais ou pas, pourquoi pas ça ?
Parceque ce n'est pas une commande du protocole et que donc on ne peux
pas le demander au serveur.
Est-ce vrai que c'est le courrielleur qui marque les messages comme lu sur le serveur, en POP ?
Euh, le protocole POP3 est destiner à "fetcher" les mails distants pour les lire en local, avec possibilité de les laisser sur le serveur.
Oui (je ne sais pas ce qu'est fetcher, mais je suppose), mais en quoi ça exclue le fait de marquer comme lu ? Il peut choisir de les supprimer ou pas, avec un délais ou pas, pourquoi pas ça ?
Parceque ce n'est pas une commande du protocole et que donc on ne peux pas le demander au serveur.
-- Les simplifications c'est trop compliqué
none
Le 08/02/2015 16:19, Eric Demeester a écrit :
Bonjour,
siger (30 Jan 2015 16:47:48 GMT - fr.comp.mail) :
Je viens de lire ce qui a déjà été dit, je vais essayer de te faire une synthèse en espérant ne pas dire trop de bêtises (compléments et corrections bienvenus).
Tu en dis trop pour une synthèse. ;-)
Avec le webmail Zimbra de Free, quand je "pope" les messages depuis mon ordinateur, ensuite je vais sur le webmail ils sont notés comme non- lus.
Mais avec un autre prestataire ils sont marqués comme lus. Ce prestataire me dit que c'est le courrielleur qui décide de ça.
S'il le fait, je n'ai trouvé aucune commande POP (voir plus bas) qui corresponde à cette possibilité.
Normal cela n'a jamais existé. :-)
Ça ressemble plutôt à une confusion côté webmail entre message lu sur le serveur au sens de « téléchargé par le courriéleur (le client) » et message lu par l'utilisateur au sens de « ouvert _dans_ le client ».
- Côté client :
En POP3, le client récupère le message x sur le serveur (RETR x), puis demande son effacement (DELE x).
Très vite, on a considéré que c'était malpratique, c'est pourquoi la plupart des clients POP peuvent différer l'effacement du message récupéré pendant un délais parémétrable de zéro à l'infini.
Il est important de comprendre que c'est un « bricolage a posteriori » et pas une fonction prévue ou définie dans la RFC
On peut ainsi consulter les messages pendant un certain temps via le webmail si on n'a pas accès a son client, télécharger les messages sur plusieurs clients, etc.
Concrètement, le client se constitue une base de données associant à chaque indentifiant de message (x) sa date de téléchargement et sa date d'effacement du serveur, c'est à dire le moment où il enverra la commande DELE x au serveur.
Quelle histoire haletante ! ;-) Cela ne présente pas d'intérêt par rapport à la question de la discussion et puis, ça concerne peu de personnes à mon avis parce qu'il faudrait déjà qu'ils sachent comment configurer leur logiciel de messagerie pour laisser les messages sur le serveur. ;-)
- Côté serveur :
Chaque message récupéré par le client (RETR x) est marqué comme lu (au sens téléchargé) par le serveur,
C'est une bêtise. Le serveur ne marque pas les messages récupérés. Cela présente aucun intérêt.
ce qui permet au client via la commande (STAT), de savoir ce qu'il doit télécharger ou pas.
En dehors, d'indiquer le nombre de messages sur le serveur et leur taille, elle ne permet pas au client de savoir ce qu'il a à récupérer sur le serveur.
Compte tenu de l'ajout de la possibilité de différer l'effacement, le client ne procède plus comme ça. Il charge la totalité des identifiants présents sur le serveur (LIST), compare au contenu de sa base de données et ne récupère que ceux qu'il n'a pas déjà.
Ce n'est pas rapport à l'effacement différé mais par rapport à la dernière récupération de messages. J'ai tendance à penser que c'est la commande UIDL et non LIST qui est employée maintenant. Le client récupère en POP le ou les messages quelque soit leur état lu ou non lu sur le serveur.
Côté serveur toujours, si un webmail est associé, ce dernier affiche tous les messages présents sur le serveur, mais doit posséder son propre marqueur permettant de savoir si le message a été lu ou non _via le webmail_, indépendamment du fait qu'il ait été ou non _téléchargé_ par le client et marqué comme tel sur le serveur.
A ma connaissance, il n'y a qu'une seule et unique boîte aux lettres, encore heureux !! ;-) Après, tu as différents moyens d'y accéder. Le POP se contente de récupérer et de supprimer les messages dans la boite de réception de la boîte aux lettres. L'IMAP consiste depuis le client à se connecter à la boîte aux lettres et de la gérer directement au niveau du serveur. Le Webmail fait ce que fait l'IMAP mais via une interface Web, non ?
- Pour en savoir plus :
La lecture de la RFC étant un peu fastidieuse, voici la liste des commandes POP échangées en TELNET entre le courriéleur et le serveur lors d'une session POP3 : (http://www.linux-france.org/article/web/egraffin/pop3.php)
USER Votre login de connexion. PASS Votre mot de passe. STAT Vous donne la taille et le nombre de message non lus. RETR x Récupére le message x. DELE x Supprime le message x
LAST Donne le numéro du dernier message accédé.
La commande LAST n'est plus dans la RFC. Elle était encore présente dans les RFC en 1993 puis elle a été supprimée fin 1994.
LIST n Taille du message n ou de tous les messages s'il n'y a pas d'argument. RSET Annule la suppression de message. TOP x Affiche l'en tête du message x. NOOP Ne rien faire. QUIT Cloture la session POP3.
Il manque la commande UIDL
Tu peux lire un exemple de dialogue client serveur ici : http://fr.wikipedia.org/wiki/Post_Office_Protocol#Exemple_de_dialogue
Aller, j'ai du en dire des conneries alors... ;-)
Le 08/02/2015 16:19, Eric Demeester a écrit :
Bonjour,
siger (30 Jan 2015 16:47:48 GMT - fr.comp.mail) :
Je viens de lire ce qui a déjà été dit, je vais essayer de te faire une
synthèse en espérant ne pas dire trop de bêtises (compléments et
corrections bienvenus).
Tu en dis trop pour une synthèse. ;-)
Avec le webmail Zimbra de Free, quand je "pope" les messages depuis mon
ordinateur, ensuite je vais sur le webmail ils sont notés comme non-
lus.
Mais avec un autre prestataire ils sont marqués comme lus.
Ce prestataire me dit que c'est le courrielleur qui décide de ça.
S'il le fait, je n'ai trouvé aucune commande POP (voir plus bas) qui
corresponde à cette possibilité.
Normal cela n'a jamais existé. :-)
Ça ressemble plutôt à une confusion côté webmail entre message lu sur le
serveur au sens de « téléchargé par le courriéleur (le client) » et
message lu par l'utilisateur au sens de « ouvert _dans_ le client ».
- Côté client :
En POP3, le client récupère le message x sur le serveur (RETR x), puis
demande son effacement (DELE x).
Très vite, on a considéré que c'était malpratique, c'est pourquoi la
plupart des clients POP peuvent différer l'effacement du message
récupéré pendant un délais parémétrable de zéro à l'infini.
Il est important de comprendre que c'est un « bricolage a posteriori »
et pas une fonction prévue ou définie dans la RFC
On peut ainsi consulter les messages pendant un certain temps via le
webmail si on n'a pas accès a son client, télécharger les messages sur
plusieurs clients, etc.
Concrètement, le client se constitue une base de données associant à
chaque indentifiant de message (x) sa date de téléchargement et sa date
d'effacement du serveur, c'est à dire le moment où il enverra la
commande DELE x au serveur.
Quelle histoire haletante ! ;-)
Cela ne présente pas d'intérêt par rapport à la question de la
discussion et puis, ça concerne peu de personnes à mon avis parce qu'il
faudrait déjà qu'ils sachent comment configurer leur logiciel de
messagerie pour laisser les messages sur le serveur. ;-)
- Côté serveur :
Chaque message récupéré par le client (RETR x) est marqué comme lu (au
sens téléchargé) par le serveur,
C'est une bêtise. Le serveur ne marque pas les messages récupérés.
Cela présente aucun intérêt.
ce qui permet au client via la commande
(STAT), de savoir ce qu'il doit télécharger ou pas.
En dehors, d'indiquer le nombre de messages sur le serveur et leur
taille, elle ne permet pas au client de savoir ce qu'il a à récupérer
sur le serveur.
Compte tenu de l'ajout de la possibilité de différer l'effacement, le
client ne procède plus comme ça. Il charge la totalité des identifiants
présents sur le serveur (LIST), compare au contenu de sa base de données
et ne récupère que ceux qu'il n'a pas déjà.
Ce n'est pas rapport à l'effacement différé mais par rapport à la
dernière récupération de messages.
J'ai tendance à penser que c'est la commande UIDL et non LIST qui est
employée maintenant.
Le client récupère en POP le ou les messages quelque soit leur état lu
ou non lu sur le serveur.
Côté serveur toujours, si un webmail est associé, ce dernier affiche
tous les messages présents sur le serveur, mais doit posséder son propre
marqueur permettant de savoir si le message a été lu ou non _via le
webmail_, indépendamment du fait qu'il ait été ou non _téléchargé_ par
le client et marqué comme tel sur le serveur.
A ma connaissance, il n'y a qu'une seule et unique boîte aux lettres,
encore heureux !! ;-)
Après, tu as différents moyens d'y accéder.
Le POP se contente de récupérer et de supprimer les messages dans la
boite de réception de la boîte aux lettres.
L'IMAP consiste depuis le client à se connecter à la boîte aux lettres
et de la gérer directement au niveau du serveur.
Le Webmail fait ce que fait l'IMAP mais via une interface Web, non ?
- Pour en savoir plus :
La lecture de la RFC étant un peu fastidieuse, voici la liste des
commandes POP échangées en TELNET entre le courriéleur et le serveur
lors d'une session POP3 :
(http://www.linux-france.org/article/web/egraffin/pop3.php)
USER Votre login de connexion.
PASS Votre mot de passe.
STAT Vous donne la taille et le nombre de message non lus.
RETR x Récupére le message x.
DELE x Supprime le message x
LAST Donne le numéro du dernier message accédé.
La commande LAST n'est plus dans la RFC.
Elle était encore présente dans les RFC en 1993 puis elle a été
supprimée fin 1994.
LIST n Taille du message n ou de tous les messages s'il n'y a pas
d'argument.
RSET Annule la suppression de message.
TOP x Affiche l'en tête du message x.
NOOP Ne rien faire.
QUIT Cloture la session POP3.
Il manque la commande UIDL
Tu peux lire un exemple de dialogue client serveur ici :
http://fr.wikipedia.org/wiki/Post_Office_Protocol#Exemple_de_dialogue
Je viens de lire ce qui a déjà été dit, je vais essayer de te faire une synthèse en espérant ne pas dire trop de bêtises (compléments et corrections bienvenus).
Tu en dis trop pour une synthèse. ;-)
Avec le webmail Zimbra de Free, quand je "pope" les messages depuis mon ordinateur, ensuite je vais sur le webmail ils sont notés comme non- lus.
Mais avec un autre prestataire ils sont marqués comme lus. Ce prestataire me dit que c'est le courrielleur qui décide de ça.
S'il le fait, je n'ai trouvé aucune commande POP (voir plus bas) qui corresponde à cette possibilité.
Normal cela n'a jamais existé. :-)
Ça ressemble plutôt à une confusion côté webmail entre message lu sur le serveur au sens de « téléchargé par le courriéleur (le client) » et message lu par l'utilisateur au sens de « ouvert _dans_ le client ».
- Côté client :
En POP3, le client récupère le message x sur le serveur (RETR x), puis demande son effacement (DELE x).
Très vite, on a considéré que c'était malpratique, c'est pourquoi la plupart des clients POP peuvent différer l'effacement du message récupéré pendant un délais parémétrable de zéro à l'infini.
Il est important de comprendre que c'est un « bricolage a posteriori » et pas une fonction prévue ou définie dans la RFC
On peut ainsi consulter les messages pendant un certain temps via le webmail si on n'a pas accès a son client, télécharger les messages sur plusieurs clients, etc.
Concrètement, le client se constitue une base de données associant à chaque indentifiant de message (x) sa date de téléchargement et sa date d'effacement du serveur, c'est à dire le moment où il enverra la commande DELE x au serveur.
Quelle histoire haletante ! ;-) Cela ne présente pas d'intérêt par rapport à la question de la discussion et puis, ça concerne peu de personnes à mon avis parce qu'il faudrait déjà qu'ils sachent comment configurer leur logiciel de messagerie pour laisser les messages sur le serveur. ;-)
- Côté serveur :
Chaque message récupéré par le client (RETR x) est marqué comme lu (au sens téléchargé) par le serveur,
C'est une bêtise. Le serveur ne marque pas les messages récupérés. Cela présente aucun intérêt.
ce qui permet au client via la commande (STAT), de savoir ce qu'il doit télécharger ou pas.
En dehors, d'indiquer le nombre de messages sur le serveur et leur taille, elle ne permet pas au client de savoir ce qu'il a à récupérer sur le serveur.
Compte tenu de l'ajout de la possibilité de différer l'effacement, le client ne procède plus comme ça. Il charge la totalité des identifiants présents sur le serveur (LIST), compare au contenu de sa base de données et ne récupère que ceux qu'il n'a pas déjà.
Ce n'est pas rapport à l'effacement différé mais par rapport à la dernière récupération de messages. J'ai tendance à penser que c'est la commande UIDL et non LIST qui est employée maintenant. Le client récupère en POP le ou les messages quelque soit leur état lu ou non lu sur le serveur.
Côté serveur toujours, si un webmail est associé, ce dernier affiche tous les messages présents sur le serveur, mais doit posséder son propre marqueur permettant de savoir si le message a été lu ou non _via le webmail_, indépendamment du fait qu'il ait été ou non _téléchargé_ par le client et marqué comme tel sur le serveur.
A ma connaissance, il n'y a qu'une seule et unique boîte aux lettres, encore heureux !! ;-) Après, tu as différents moyens d'y accéder. Le POP se contente de récupérer et de supprimer les messages dans la boite de réception de la boîte aux lettres. L'IMAP consiste depuis le client à se connecter à la boîte aux lettres et de la gérer directement au niveau du serveur. Le Webmail fait ce que fait l'IMAP mais via une interface Web, non ?
- Pour en savoir plus :
La lecture de la RFC étant un peu fastidieuse, voici la liste des commandes POP échangées en TELNET entre le courriéleur et le serveur lors d'une session POP3 : (http://www.linux-france.org/article/web/egraffin/pop3.php)
USER Votre login de connexion. PASS Votre mot de passe. STAT Vous donne la taille et le nombre de message non lus. RETR x Récupére le message x. DELE x Supprime le message x
LAST Donne le numéro du dernier message accédé.
La commande LAST n'est plus dans la RFC. Elle était encore présente dans les RFC en 1993 puis elle a été supprimée fin 1994.
LIST n Taille du message n ou de tous les messages s'il n'y a pas d'argument. RSET Annule la suppression de message. TOP x Affiche l'en tête du message x. NOOP Ne rien faire. QUIT Cloture la session POP3.
Il manque la commande UIDL
Tu peux lire un exemple de dialogue client serveur ici : http://fr.wikipedia.org/wiki/Post_Office_Protocol#Exemple_de_dialogue
Aller, j'ai du en dire des conneries alors... ;-)
Eric Demeester
Bonsoir,
none (Sun, 08 Feb 2015 19:42:56 +0100 - fr.comp.mail) :
Tu en dis trop pour une synthèse. ;-)
Dont pas mal de bêtises, à te lire :)
Il manque la commande UIDL
Effectivement, et c'est d'autant plus regrettable que :
« UIDL : affiche (pour un seul ou pour tous les messages) un identifiant unique qui ne varie pas entre chaque session » (http://fr.wikipedia.org/wiki/Post_Office_Protocol#Commandes)
c'est effectivement ça qui est utilisé et pas LIST. Grmbl, ça m'apprendra à mieux lire.
Aller, j'ai du en dire des conneries alors... ;-)
Merci d'avoir corrigé les miennes en tout cas.
Bonsoir,
none (Sun, 08 Feb 2015 19:42:56 +0100 - fr.comp.mail) :
Tu en dis trop pour une synthèse. ;-)
Dont pas mal de bêtises, à te lire :)
Il manque la commande UIDL
Effectivement, et c'est d'autant plus regrettable que :
« UIDL : affiche (pour un seul ou pour tous les messages) un identifiant
unique qui ne varie pas entre chaque session »
(http://fr.wikipedia.org/wiki/Post_Office_Protocol#Commandes)
c'est effectivement ça qui est utilisé et pas LIST. Grmbl, ça
m'apprendra à mieux lire.
none (Sun, 08 Feb 2015 19:42:56 +0100 - fr.comp.mail) :
Tu en dis trop pour une synthèse. ;-)
Dont pas mal de bêtises, à te lire :)
Il manque la commande UIDL
Effectivement, et c'est d'autant plus regrettable que :
« UIDL : affiche (pour un seul ou pour tous les messages) un identifiant unique qui ne varie pas entre chaque session » (http://fr.wikipedia.org/wiki/Post_Office_Protocol#Commandes)
c'est effectivement ça qui est utilisé et pas LIST. Grmbl, ça m'apprendra à mieux lire.
Aller, j'ai du en dire des conneries alors... ;-)
Merci d'avoir corrigé les miennes en tout cas.
siger
Eric Demeester a écrit :
- Côté serveur :
Chaque message récupéré par le client (RETR x) est marqué comme lu (au sens téléchargé) par le serveur, ce qui permet au client via la commande (STAT), de savoir ce qu'il doit télécharger ou pas.
Quand je vais sur le Zimbra de Free, les messages déjà téléchargés en POP sont non-lus, il y a donc bien une différenciation.
Ça ressemble plutôt à une confusion côté webmail entre message lu sur le serveur au sens de « téléchargé par le courriéleur (le client) » et message lu par l'utilisateur au sens de « ouvert _dans_ le client ».
C'est en tous cas ce que je constate sur cet autre webmail.
Vu cet avis et les autres avis, il me semble devoir conclure que le prestataire se trompe quand il dit que "marquer comme lu" sur le serveur quand le message est téléchargé en POP est dû au courrielleur.
-- siger
Eric Demeester a écrit :
- Côté serveur :
Chaque message récupéré par le client (RETR x) est marqué comme lu
(au sens téléchargé) par le serveur, ce qui permet au client via
la commande (STAT), de savoir ce qu'il doit télécharger ou pas.
Quand je vais sur le Zimbra de Free, les messages déjà téléchargés
en POP sont non-lus, il y a donc bien une différenciation.
Ça ressemble plutôt à une confusion côté webmail entre message lu
sur le serveur au sens de « téléchargé par le courriéleur (le
client) » et message lu par l'utilisateur au sens de « ouvert
_dans_ le client ».
C'est en tous cas ce que je constate sur cet autre webmail.
Vu cet avis et les autres avis, il me semble devoir conclure que le
prestataire se trompe quand il dit que "marquer comme lu" sur le
serveur quand le message est téléchargé en POP est dû au courrielleur.
Chaque message récupéré par le client (RETR x) est marqué comme lu (au sens téléchargé) par le serveur, ce qui permet au client via la commande (STAT), de savoir ce qu'il doit télécharger ou pas.
Quand je vais sur le Zimbra de Free, les messages déjà téléchargés en POP sont non-lus, il y a donc bien une différenciation.
Ça ressemble plutôt à une confusion côté webmail entre message lu sur le serveur au sens de « téléchargé par le courriéleur (le client) » et message lu par l'utilisateur au sens de « ouvert _dans_ le client ».
C'est en tous cas ce que je constate sur cet autre webmail.
Vu cet avis et les autres avis, il me semble devoir conclure que le prestataire se trompe quand il dit que "marquer comme lu" sur le serveur quand le message est téléchargé en POP est dû au courrielleur.
-- siger
none
Le 08/02/2015 22:52, Eric Demeester a écrit :
Il manque la commande UIDL
Effectivement, et c'est d'autant plus regrettable que :
« UIDL : affiche (pour un seul ou pour tous les messages) un identifiant unique qui ne varie pas entre chaque session » (http://fr.wikipedia.org/wiki/Post_Office_Protocol#Commandes)
c'est effectivement ça qui est utilisé et pas LIST. Grmbl, ça m'apprendra à mieux lire.
D'ailleurs, dans le source de chaque message récupéré en POP, on trouve parmi les entêtes ajoutées par Thunderbird : X-UIDL ;-)
Le 08/02/2015 22:52, Eric Demeester a écrit :
Il manque la commande UIDL
Effectivement, et c'est d'autant plus regrettable que :
« UIDL : affiche (pour un seul ou pour tous les messages) un identifiant
unique qui ne varie pas entre chaque session »
(http://fr.wikipedia.org/wiki/Post_Office_Protocol#Commandes)
c'est effectivement ça qui est utilisé et pas LIST. Grmbl, ça
m'apprendra à mieux lire.
D'ailleurs, dans le source de chaque message récupéré en POP, on trouve
parmi les entêtes ajoutées par Thunderbird : X-UIDL ;-)
Effectivement, et c'est d'autant plus regrettable que :
« UIDL : affiche (pour un seul ou pour tous les messages) un identifiant unique qui ne varie pas entre chaque session » (http://fr.wikipedia.org/wiki/Post_Office_Protocol#Commandes)
c'est effectivement ça qui est utilisé et pas LIST. Grmbl, ça m'apprendra à mieux lire.
D'ailleurs, dans le source de chaque message récupéré en POP, on trouve parmi les entêtes ajoutées par Thunderbird : X-UIDL ;-)
Ego
Le 09/02/15 09:44, siger a écrit :
Eric Demeester a écrit :
- Côté serveur :
Chaque message récupéré par le client (RETR x) est marqué comme lu (au sens téléchargé) par le serveur, ce qui permet au client via la commande (STAT), de savoir ce qu'il doit télécharger ou pas.
Quand je vais sur le Zimbra de Free, les messages déjà téléchargés en POP sont non-lus, il y a donc bien une différenciation.
webmail = IMAP
donc webmail != POP3
Le 09/02/15 09:44, siger a écrit :
Eric Demeester a écrit :
- Côté serveur :
Chaque message récupéré par le client (RETR x) est marqué comme lu
(au sens téléchargé) par le serveur, ce qui permet au client via
la commande (STAT), de savoir ce qu'il doit télécharger ou pas.
Quand je vais sur le Zimbra de Free, les messages déjà téléchargés
en POP sont non-lus, il y a donc bien une différenciation.
Chaque message récupéré par le client (RETR x) est marqué comme lu (au sens téléchargé) par le serveur, ce qui permet au client via la commande (STAT), de savoir ce qu'il doit télécharger ou pas.
Quand je vais sur le Zimbra de Free, les messages déjà téléchargés en POP sont non-lus, il y a donc bien une différenciation.
webmail = IMAP
donc webmail != POP3
siger
Ego a écrit :
Le 09/02/15 09:44, siger a écrit :
Eric Demeester a écrit :
- Côté serveur : Chaque message récupéré par le client (RETR x) est marqué comme lu (au sens téléchargé) par le serveur, ce qui permet au client via la commande (STAT), de savoir ce qu'il doit télécharger ou pas.
Quand je vais sur le Zimbra de Free, les messages déjà téléchargés en POP sont non-lus, il y a donc bien une différenciation.
webmail = IMAP donc webmail != POP3
Je suppose que != signifie "est différent de".
Que je sache, IMAP et POP3 sont des manières de communiquer entre un webmail et un courrielleur, ou entre 2 webmail. Donc je ne comprends pas ces 2 affirmations.
Et même si tu as raison, je ne comprends pas non plus le sens de ta réponse.
-- siger
Ego a écrit :
Le 09/02/15 09:44, siger a écrit :
Eric Demeester a écrit :
- Côté serveur :
Chaque message récupéré par le client (RETR x) est marqué comme lu
(au sens téléchargé) par le serveur, ce qui permet au client via
la commande (STAT), de savoir ce qu'il doit télécharger ou pas.
Quand je vais sur le Zimbra de Free, les messages déjà téléchargés
en POP sont non-lus, il y a donc bien une différenciation.
webmail = IMAP
donc webmail != POP3
Je suppose que != signifie "est différent de".
Que je sache, IMAP et POP3 sont des manières de communiquer entre un
webmail et un courrielleur, ou entre 2 webmail. Donc je ne comprends
pas ces 2 affirmations.
Et même si tu as raison, je ne comprends pas non plus le sens de
ta réponse.
- Côté serveur : Chaque message récupéré par le client (RETR x) est marqué comme lu (au sens téléchargé) par le serveur, ce qui permet au client via la commande (STAT), de savoir ce qu'il doit télécharger ou pas.
Quand je vais sur le Zimbra de Free, les messages déjà téléchargés en POP sont non-lus, il y a donc bien une différenciation.
webmail = IMAP donc webmail != POP3
Je suppose que != signifie "est différent de".
Que je sache, IMAP et POP3 sont des manières de communiquer entre un webmail et un courrielleur, ou entre 2 webmail. Donc je ne comprends pas ces 2 affirmations.
Et même si tu as raison, je ne comprends pas non plus le sens de ta réponse.
-- siger
DV
siger a écrit :
webmail = IMAP > donc webmail != POP3
Je suppose que != signifie "est différent de".
Que je sache, IMAP et POP3 sont des manières de communiquer entre un webmail et un courrielleur, ou entre 2 webmail. Donc je ne comprends pas ces 2 affirmations.
Si l'on ajoutait l'équation :
webmail != serveur
est-ce que ce serait plus clair ? ;-)
IMAP et POP3 permettent de communiquer entre un *serveur de messagerie* et un courrielleur. Le webmail n'est pas le serveur, c'est juste une interface qui permet d'accéder au contenu du serveur. En gros, c'est un courrielleur qui s'affiche dans ton navigateur. Et comme le suggère Ego, les webmails utilisent exclusivement le protocole IMAP.
-- DV
siger a écrit :
webmail = IMAP
> donc webmail != POP3
Je suppose que != signifie "est différent de".
Que je sache, IMAP et POP3 sont des manières de communiquer entre un
webmail et un courrielleur, ou entre 2 webmail. Donc je ne comprends
pas ces 2 affirmations.
Si l'on ajoutait l'équation :
webmail != serveur
est-ce que ce serait plus clair ? ;-)
IMAP et POP3 permettent de communiquer entre un *serveur de messagerie*
et un courrielleur. Le webmail n'est pas le serveur, c'est juste une
interface qui permet d'accéder au contenu du serveur. En gros, c'est un
courrielleur qui s'affiche dans ton navigateur. Et comme le suggère Ego,
les webmails utilisent exclusivement le protocole IMAP.
Que je sache, IMAP et POP3 sont des manières de communiquer entre un webmail et un courrielleur, ou entre 2 webmail. Donc je ne comprends pas ces 2 affirmations.
Si l'on ajoutait l'équation :
webmail != serveur
est-ce que ce serait plus clair ? ;-)
IMAP et POP3 permettent de communiquer entre un *serveur de messagerie* et un courrielleur. Le webmail n'est pas le serveur, c'est juste une interface qui permet d'accéder au contenu du serveur. En gros, c'est un courrielleur qui s'affiche dans ton navigateur. Et comme le suggère Ego, les webmails utilisent exclusivement le protocole IMAP.
-- DV
siger
DV a écrit :
siger a écrit :
webmail = IMAP > donc webmail != POP3
Je suppose que != signifie "est différent de".
Que je sache, IMAP et POP3 sont des manières de communiquer entre un webmail et un courrielleur, ou entre 2 webmail. Donc je ne comprends pas ces 2 affirmations.
Si l'on ajoutait l'équation :
webmail != serveur
est-ce que ce serait plus clair ? ;-)
IMAP et POP3 permettent de communiquer entre un *serveur de messagerie* et un courrielleur. Le webmail n'est pas le serveur, c'est juste une interface qui permet d'accéder au contenu du serveur.
Oui, c'est un abus de langage du fait de l'usage de l'utilisateur qui fait que serveur = webmail, mais je suis d'accord, autant être juste, Merci à Ego et toi d'avoir rectifié.
Mais je ne comprends pas la réponse. Ou alors c'était juste pour pointer du doigt mon abus de langage ?
Je ne sais pas qui du webmail ou du serveur (puisqu'apparemment ce n'est pas le courrielleur) marque ou pas les messages "popés" comme lus sur le webmail, et je ne sais pas pourquoi ce n'est pas partout pareil :-)
-- siger
DV a écrit :
siger a écrit :
webmail = IMAP
> donc webmail != POP3
Je suppose que != signifie "est différent de".
Que je sache, IMAP et POP3 sont des manières de communiquer entre
un webmail et un courrielleur, ou entre 2 webmail. Donc je ne
comprends pas ces 2 affirmations.
Si l'on ajoutait l'équation :
webmail != serveur
est-ce que ce serait plus clair ? ;-)
IMAP et POP3 permettent de communiquer entre un *serveur de
messagerie* et un courrielleur. Le webmail n'est pas le serveur,
c'est juste une interface qui permet d'accéder au contenu du
serveur.
Oui, c'est un abus de langage du fait de l'usage de l'utilisateur qui
fait que serveur = webmail, mais je suis d'accord, autant être juste,
Merci à Ego et toi d'avoir rectifié.
Mais je ne comprends pas la réponse. Ou alors c'était juste pour
pointer du doigt mon abus de langage ?
Je ne sais pas qui du webmail ou du serveur (puisqu'apparemment ce
n'est pas le courrielleur) marque ou pas les messages "popés" comme lus
sur le webmail, et je ne sais pas pourquoi ce n'est pas partout pareil
:-)
Que je sache, IMAP et POP3 sont des manières de communiquer entre un webmail et un courrielleur, ou entre 2 webmail. Donc je ne comprends pas ces 2 affirmations.
Si l'on ajoutait l'équation :
webmail != serveur
est-ce que ce serait plus clair ? ;-)
IMAP et POP3 permettent de communiquer entre un *serveur de messagerie* et un courrielleur. Le webmail n'est pas le serveur, c'est juste une interface qui permet d'accéder au contenu du serveur.
Oui, c'est un abus de langage du fait de l'usage de l'utilisateur qui fait que serveur = webmail, mais je suis d'accord, autant être juste, Merci à Ego et toi d'avoir rectifié.
Mais je ne comprends pas la réponse. Ou alors c'était juste pour pointer du doigt mon abus de langage ?
Je ne sais pas qui du webmail ou du serveur (puisqu'apparemment ce n'est pas le courrielleur) marque ou pas les messages "popés" comme lus sur le webmail, et je ne sais pas pourquoi ce n'est pas partout pareil :-)
