Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Serge Paccalin
Le mercredi 11 avril 2007 à 15:17:56, a écrit dans fr.comp.mail :
Admettons que j'envoie un mail depuis un courielleur vers un serveur de mail.
Ce courrier a 1 personne en CC: et 2 en CCi.
Du point de vue réseau entre le courielleur et le serveur de mail, combien vont transiter? 1? 3?
Un.
En fait, utiliser To, CC ou BCC (francisé en CCi) ne change rien à l'acheminement du courriel, tous les destinataires sont « à égalité » et le recevront ; ça ne change que le contenu (et le comportement des destinataires) : les champs To et CC seront présents et visibles, pas le champ CCi.
Qui s'occupe de gérer le champ CCi?
Votre courrielleur.
-- ___________ _/ _ _`_`_`_) Serge PACCALIN -- sp ad mailclub.net _L_) Pour bien répondre avec Google, ne pas cliquer -'(__) « Répondre », mais « Afficher les options », _/___(_) puis cliquer « Répondre » (parmi les options).
Le mercredi 11 avril 2007 à 15:17:56, octane@alinto.com a écrit dans
fr.comp.mail :
Admettons que j'envoie un mail depuis un courielleur vers un serveur
de mail.
Ce courrier a 1 personne en CC: et 2 en CCi.
Du point de vue réseau entre le courielleur et le serveur de mail,
combien
vont transiter?
1? 3?
Un.
En fait, utiliser To, CC ou BCC (francisé en CCi) ne change rien à
l'acheminement du courriel, tous les destinataires sont « à égalité »
et le recevront ; ça ne change que le contenu (et le comportement des
destinataires) : les champs To et CC seront présents et visibles, pas le
champ CCi.
Qui s'occupe de gérer le champ CCi?
Votre courrielleur.
--
___________
_/ _ _`_`_`_) Serge PACCALIN -- sp ad mailclub.net
_L_) Pour bien répondre avec Google, ne pas cliquer
-'(__) « Répondre », mais « Afficher les options »,
_/___(_) puis cliquer « Répondre » (parmi les options).
Le mercredi 11 avril 2007 à 15:17:56, a écrit dans fr.comp.mail :
Admettons que j'envoie un mail depuis un courielleur vers un serveur de mail.
Ce courrier a 1 personne en CC: et 2 en CCi.
Du point de vue réseau entre le courielleur et le serveur de mail, combien vont transiter? 1? 3?
Un.
En fait, utiliser To, CC ou BCC (francisé en CCi) ne change rien à l'acheminement du courriel, tous les destinataires sont « à égalité » et le recevront ; ça ne change que le contenu (et le comportement des destinataires) : les champs To et CC seront présents et visibles, pas le champ CCi.
Qui s'occupe de gérer le champ CCi?
Votre courrielleur.
-- ___________ _/ _ _`_`_`_) Serge PACCALIN -- sp ad mailclub.net _L_) Pour bien répondre avec Google, ne pas cliquer -'(__) « Répondre », mais « Afficher les options », _/___(_) puis cliquer « Répondre » (parmi les options).
Erwan David
écrivait :
Bonjour,
Admettons que j'envoie un mail depuis un courielleur vers un serveur de mail.
Ce courrier a 1 personne en CC: et 2 en CCi.
Du point de vue réseau entre le courielleur et le serveur de mail, combien vont transiter? 1? 3?
Qui s'occupe de gérer le champ CCi?
Il ne faut pas confondre l'enveloppe (qui sers à acheminer le courier) et les en-têtes (qui sont lus par le destinataire).
Dans votre cas on aura une enveloppe avec 3 destinataires, mais un seul sera indiqué dans les en-têtes. Lors de la distribution du courier, les mentions d'enveloppe sont masquées, ce qui explique qu'on ne voie pas le CCi.
Votre logiciel enverra aura donc un dialogue avec le serveur de la forme
-> Bonjour <- Bonjour // les agents de courier sont polis, ils commencent toujours par dire bonjour
-> voici un message de <votre adresse> <- d'accord
-> il faut l'envoyer à <destinataire 1> <- d'accord
-> il faut l'envoyer à <destinataire 2> <- d'accord
-> il faut l'envoyer à <destinataire 3> <- d'accord
-> voici le message <- envoyez le, et terminez par un . tout seul sur sa ligne
... ... Le message avec ses en-têtes dont celui donnant un seul .... destinataire
.... .... .
<- C'est bon je m'en occupe -> au revoir
-- Erwan
octane@alinto.com écrivait :
Bonjour,
Admettons que j'envoie un mail depuis un courielleur vers un serveur
de mail.
Ce courrier a 1 personne en CC: et 2 en CCi.
Du point de vue réseau entre le courielleur et le serveur de mail,
combien
vont transiter?
1? 3?
Qui s'occupe de gérer le champ CCi?
Il ne faut pas confondre l'enveloppe (qui sers à acheminer le courier)
et les en-têtes (qui sont lus par le destinataire).
Dans votre cas on aura une enveloppe avec 3 destinataires, mais un
seul sera indiqué dans les en-têtes. Lors de la distribution du
courier, les mentions d'enveloppe sont masquées, ce qui explique qu'on
ne voie pas le CCi.
Votre logiciel enverra aura donc un dialogue avec le serveur de la
forme
-> Bonjour
<- Bonjour // les agents de courier sont polis, ils commencent
toujours par dire bonjour
-> voici un message de <votre adresse>
<- d'accord
-> il faut l'envoyer à <destinataire 1>
<- d'accord
-> il faut l'envoyer à <destinataire 2>
<- d'accord
-> il faut l'envoyer à <destinataire 3>
<- d'accord
-> voici le message
<- envoyez le, et terminez par un . tout seul sur sa ligne
...
... Le message avec ses en-têtes dont celui donnant un seul
.... destinataire
Admettons que j'envoie un mail depuis un courielleur vers un serveur de mail.
Ce courrier a 1 personne en CC: et 2 en CCi.
Du point de vue réseau entre le courielleur et le serveur de mail, combien vont transiter? 1? 3?
Qui s'occupe de gérer le champ CCi?
Il ne faut pas confondre l'enveloppe (qui sers à acheminer le courier) et les en-têtes (qui sont lus par le destinataire).
Dans votre cas on aura une enveloppe avec 3 destinataires, mais un seul sera indiqué dans les en-têtes. Lors de la distribution du courier, les mentions d'enveloppe sont masquées, ce qui explique qu'on ne voie pas le CCi.
Votre logiciel enverra aura donc un dialogue avec le serveur de la forme
-> Bonjour <- Bonjour // les agents de courier sont polis, ils commencent toujours par dire bonjour
-> voici un message de <votre adresse> <- d'accord
-> il faut l'envoyer à <destinataire 1> <- d'accord
-> il faut l'envoyer à <destinataire 2> <- d'accord
-> il faut l'envoyer à <destinataire 3> <- d'accord
-> voici le message <- envoyez le, et terminez par un . tout seul sur sa ligne
... ... Le message avec ses en-têtes dont celui donnant un seul .... destinataire
.... .... .
<- C'est bon je m'en occupe -> au revoir
-- Erwan
octane
On 11 avr, 17:29, Erwan David wrote:
Admettons que j'envoie un mail depuis un courielleur vers un serveur de mail.
Ce courrier a 1 personne en CC: et 2 en CCi.
Du point de vue réseau entre le courielleur et le serveur de mail, combien vont transiter? 1? 3?
Qui s'occupe de gérer le champ CCi?
Il ne faut pas confondre l'enveloppe (qui sers à acheminer le courier) et les en-têtes (qui sont lus par le destinataire).
ok.
Dans votre cas on aura une enveloppe avec 3 destinataires, mais un seul sera indiqué dans les en-têtes. Lors de la distribution du courier, les mentions d'enveloppe sont masquées, ce qui explique qu'on ne voie pas le CCi.
ok, donc c'est bien le courrieleur qui s'occupe de lire le CCi et de
le supprimer. Il met en forme ensuite l'enveloppe.
Votre logiciel enverra aura donc un dialogue avec le serveur de la forme
-> Bonjour <- Bonjour // les agents de courier sont polis, ils commencent toujours par dire bonjour
j'ai lance wireshark et curieusement je vois:
EHLO <mon nom> 500 Syntax Error, command not understood HELO <mon nom> 250 <server> pleased to meet you, <mon nom> RSET 250 OK Mail FROM: etc..
je ne comprends pas pourquoi le EHLO est refuse (?) c'est standard depuis pas mal d'annees quand meme. Le serveur est un sendmail linux. Je ne comprends pas non plus pourquoi le client envoie un RSET (j'ai teste plusieurs fois et il envoie toujours un RSET apres le HELO).
Le client est sendmail.exe sous windows (rien a voir avec un portage unix, meme cygwin)
-> il faut l'envoyer à <destinataire 1> <- d'accord
-> il faut l'envoyer à <destinataire 2> <- d'accord
-> il faut l'envoyer à <destinataire 3> <- d'accord
Il y a une limite dans le nombre de destinataire? Je ne
vois rien dans la RFC2821 la dessus (??)
On 11 avr, 17:29, Erwan David <e...@rail.eu.org> wrote:
Admettons que j'envoie un mail depuis un courielleur vers un serveur
de mail.
Ce courrier a 1 personne en CC: et 2 en CCi.
Du point de vue réseau entre le courielleur et le serveur de mail,
combien
vont transiter?
1? 3?
Qui s'occupe de gérer le champ CCi?
Il ne faut pas confondre l'enveloppe (qui sers à acheminer le courier)
et les en-têtes (qui sont lus par le destinataire).
ok.
Dans votre cas on aura une enveloppe avec 3 destinataires, mais un
seul sera indiqué dans les en-têtes. Lors de la distribution du
courier, les mentions d'enveloppe sont masquées, ce qui explique qu'on
ne voie pas le CCi.
ok, donc c'est bien le courrieleur qui s'occupe de lire le CCi et de
le supprimer. Il met en forme ensuite l'enveloppe.
Votre logiciel enverra aura donc un dialogue avec le serveur de la
forme
-> Bonjour
<- Bonjour // les agents de courier sont polis, ils commencent
toujours par dire bonjour
j'ai lance wireshark et curieusement je vois:
EHLO <mon nom>
500 Syntax Error, command not understood
HELO <mon nom>
250 <server> pleased to meet you, <mon nom>
RSET
250 OK
Mail FROM:
etc..
je ne comprends pas pourquoi le EHLO est refuse (?) c'est
standard depuis pas mal d'annees quand meme. Le serveur est
un sendmail linux.
Je ne comprends pas non plus pourquoi le client envoie un
RSET (j'ai teste plusieurs fois et il envoie toujours un
RSET apres le HELO).
Le client est sendmail.exe sous windows (rien a voir
avec un portage unix, meme cygwin)
-> il faut l'envoyer à <destinataire 1>
<- d'accord
-> il faut l'envoyer à <destinataire 2>
<- d'accord
-> il faut l'envoyer à <destinataire 3>
<- d'accord
Il y a une limite dans le nombre de destinataire? Je ne
Admettons que j'envoie un mail depuis un courielleur vers un serveur de mail.
Ce courrier a 1 personne en CC: et 2 en CCi.
Du point de vue réseau entre le courielleur et le serveur de mail, combien vont transiter? 1? 3?
Qui s'occupe de gérer le champ CCi?
Il ne faut pas confondre l'enveloppe (qui sers à acheminer le courier) et les en-têtes (qui sont lus par le destinataire).
ok.
Dans votre cas on aura une enveloppe avec 3 destinataires, mais un seul sera indiqué dans les en-têtes. Lors de la distribution du courier, les mentions d'enveloppe sont masquées, ce qui explique qu'on ne voie pas le CCi.
ok, donc c'est bien le courrieleur qui s'occupe de lire le CCi et de
le supprimer. Il met en forme ensuite l'enveloppe.
Votre logiciel enverra aura donc un dialogue avec le serveur de la forme
-> Bonjour <- Bonjour // les agents de courier sont polis, ils commencent toujours par dire bonjour
j'ai lance wireshark et curieusement je vois:
EHLO <mon nom> 500 Syntax Error, command not understood HELO <mon nom> 250 <server> pleased to meet you, <mon nom> RSET 250 OK Mail FROM: etc..
je ne comprends pas pourquoi le EHLO est refuse (?) c'est standard depuis pas mal d'annees quand meme. Le serveur est un sendmail linux. Je ne comprends pas non plus pourquoi le client envoie un RSET (j'ai teste plusieurs fois et il envoie toujours un RSET apres le HELO).
Le client est sendmail.exe sous windows (rien a voir avec un portage unix, meme cygwin)
-> il faut l'envoyer à <destinataire 1> <- d'accord
-> il faut l'envoyer à <destinataire 2> <- d'accord
-> il faut l'envoyer à <destinataire 3> <- d'accord
Il y a une limite dans le nombre de destinataire? Je ne
vois rien dans la RFC2821 la dessus (??)
ts
"o" == octane writes:
o> je ne comprends pas pourquoi le EHLO est refuse (?) c'est o> standard depuis pas mal d'annees quand meme. Le serveur est o> un sendmail linux.
Le protocole avec EHLO offre plus de possibilités et est plus "verbeux". Certains serveurs SMTP, n'ayant pas besoin de ces "fioritures", vont le refuser pour diminuer la charge de leur serveur.
o> Je ne comprends pas non plus pourquoi le client envoie un o> RSET (j'ai teste plusieurs fois et il envoie toujours un o> RSET apres le HELO).
Il faudrait voir avec les programmeurs "torturés" de Delphi :-)
o> Le client est sendmail.exe sous windows (rien a voir o> avec un portage unix, meme cygwin)
Si c'est le sendmail.exe qui est écrit en Delphi à partir des sources Indy, il envoit effectivement un RSET avant le MAIL FROM si l'option PIPELINE n'a pas été proposé par le serveur.
o> Il y a une limite dans le nombre de destinataire? Je ne o> vois rien dans la RFC2821 la dessus (??)
Il n'y a pas de limite supérieure mais une limite inférieure (100) définie dans le paragraphe "recipients buffer" avec notamment ce passage
100 recipients. Rejection of messages (for excessive recipients) with fewer than 100 RCPT commands is a violation of this specification.
Ce que faisait yahoo à une époque.
--
Guy Decoux
"o" == octane <octane@alinto.com> writes:
o> je ne comprends pas pourquoi le EHLO est refuse (?) c'est
o> standard depuis pas mal d'annees quand meme. Le serveur est
o> un sendmail linux.
Le protocole avec EHLO offre plus de possibilités et est plus
"verbeux". Certains serveurs SMTP, n'ayant pas besoin de ces "fioritures",
vont le refuser pour diminuer la charge de leur serveur.
o> Je ne comprends pas non plus pourquoi le client envoie un
o> RSET (j'ai teste plusieurs fois et il envoie toujours un
o> RSET apres le HELO).
Il faudrait voir avec les programmeurs "torturés" de Delphi :-)
o> Le client est sendmail.exe sous windows (rien a voir
o> avec un portage unix, meme cygwin)
Si c'est le sendmail.exe qui est écrit en Delphi à partir des sources
Indy, il envoit effectivement un RSET avant le MAIL FROM si l'option
PIPELINE n'a pas été proposé par le serveur.
o> Il y a une limite dans le nombre de destinataire? Je ne
o> vois rien dans la RFC2821 la dessus (??)
Il n'y a pas de limite supérieure mais une limite inférieure (100) définie
dans le paragraphe "recipients buffer" avec notamment ce passage
100 recipients. Rejection of messages (for excessive recipients)
with fewer than 100 RCPT commands is a violation of this
specification.
o> je ne comprends pas pourquoi le EHLO est refuse (?) c'est o> standard depuis pas mal d'annees quand meme. Le serveur est o> un sendmail linux.
Le protocole avec EHLO offre plus de possibilités et est plus "verbeux". Certains serveurs SMTP, n'ayant pas besoin de ces "fioritures", vont le refuser pour diminuer la charge de leur serveur.
o> Je ne comprends pas non plus pourquoi le client envoie un o> RSET (j'ai teste plusieurs fois et il envoie toujours un o> RSET apres le HELO).
Il faudrait voir avec les programmeurs "torturés" de Delphi :-)
o> Le client est sendmail.exe sous windows (rien a voir o> avec un portage unix, meme cygwin)
Si c'est le sendmail.exe qui est écrit en Delphi à partir des sources Indy, il envoit effectivement un RSET avant le MAIL FROM si l'option PIPELINE n'a pas été proposé par le serveur.
o> Il y a une limite dans le nombre de destinataire? Je ne o> vois rien dans la RFC2821 la dessus (??)
Il n'y a pas de limite supérieure mais une limite inférieure (100) définie dans le paragraphe "recipients buffer" avec notamment ce passage
100 recipients. Rejection of messages (for excessive recipients) with fewer than 100 RCPT commands is a violation of this specification.
