Existe-t-il dans les normes relatives à l'e-mail (RFC), quelque chose
qui permette (et qui garantisse) de corréler un e-mail de retour
d'erreur, quelque soit la raison (destinaire inconnu, bal saturée,
...), à l'e-mail initial ?
J'ai regardé les RFC 2821 et 2822 et je n'ai rien trouvé (mais ça a pu
m'échapper).
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
F. Senault
Existe-t-il dans les normes relatives à l'e-mail (RFC), quelque chose qui permette (et qui garantisse) de corréler un e-mail de retour d'erreur, quelque soit la raison (destinaire inconnu, bal saturée, ...), à l'e-mail initial ? J'ai regardé les RFC 2821 et 2822 et je n'ai rien trouvé (mais ça a pu m'échapper).
Jette déjà un oeil à la RFC 3463 (Enhanced System Status Codes). Je ne sais pas si c'est ce que tu cherches, mais...
Fred -- Look at you now Eyes wide open Truth begged to be told I want to make you feel this Trusting arms let me fall once again I stood close to an enemy and closer to a friend Ties that bind you have been severed. (Kittie, Severed)
Existe-t-il dans les normes relatives à l'e-mail (RFC), quelque chose
qui permette (et qui garantisse) de corréler un e-mail de retour
d'erreur, quelque soit la raison (destinaire inconnu, bal saturée,
...), à l'e-mail initial ?
J'ai regardé les RFC 2821 et 2822 et je n'ai rien trouvé (mais ça a pu
m'échapper).
Jette déjà un oeil à la RFC 3463 (Enhanced System Status Codes). Je ne
sais pas si c'est ce que tu cherches, mais...
Fred
--
Look at you now Eyes wide open Truth begged to be told
I want to make you feel this Trusting arms let me fall once again
I stood close to an enemy and closer to a friend
Ties that bind you have been severed. (Kittie, Severed)
Existe-t-il dans les normes relatives à l'e-mail (RFC), quelque chose qui permette (et qui garantisse) de corréler un e-mail de retour d'erreur, quelque soit la raison (destinaire inconnu, bal saturée, ...), à l'e-mail initial ? J'ai regardé les RFC 2821 et 2822 et je n'ai rien trouvé (mais ça a pu m'échapper).
Jette déjà un oeil à la RFC 3463 (Enhanced System Status Codes). Je ne sais pas si c'est ce que tu cherches, mais...
Fred -- Look at you now Eyes wide open Truth begged to be told I want to make you feel this Trusting arms let me fall once again I stood close to an enemy and closer to a friend Ties that bind you have been severed. (Kittie, Severed)
Fabien LE LEZ
On 30 Aug 2004 05:47:06 -0700, (Tristan):
Existe-t-il dans les normes relatives à l'e-mail (RFC), quelque chose qui permette (et qui garantisse) de corréler un e-mail de retour d'erreur, quelque soit la raison (destinaire inconnu, bal saturée, ...), à l'e-mail initial ?
A priori, la seule piste que je vois serait le message-id du message original. Mais c'est pas forcément garanti... La variété des formats pour ce fameux message d'erreur est assez impressionnante :-/
-- ;-)
On 30 Aug 2004 05:47:06 -0700, 3stan@ifrance.com (Tristan):
Existe-t-il dans les normes relatives à l'e-mail (RFC), quelque chose
qui permette (et qui garantisse) de corréler un e-mail de retour
d'erreur, quelque soit la raison (destinaire inconnu, bal saturée,
...), à l'e-mail initial ?
A priori, la seule piste que je vois serait le message-id du message
original. Mais c'est pas forcément garanti...
La variété des formats pour ce fameux message d'erreur est assez
impressionnante :-/
Existe-t-il dans les normes relatives à l'e-mail (RFC), quelque chose qui permette (et qui garantisse) de corréler un e-mail de retour d'erreur, quelque soit la raison (destinaire inconnu, bal saturée, ...), à l'e-mail initial ?
A priori, la seule piste que je vois serait le message-id du message original. Mais c'est pas forcément garanti... La variété des formats pour ce fameux message d'erreur est assez impressionnante :-/
-- ;-)
3stan
Fabien LE LEZ wrote in message news:...
On 30 Aug 2004 05:47:06 -0700, Tristan:
Existe-t-il dans les normes relatives à l'e-mail (RFC), quelque chose qui permette (et qui garantisse) de corréler un e-mail de retour d'erreur, quelque soit la raison (destinaire inconnu, bal saturée, ...), à l'e-mail initial ?
A priori, la seule piste que je vois serait le message-id du message original. Mais c'est pas forcément garanti...
Le 1er test que j'ai fait est négatif (bien sûr, il dépend du système utilisé). La RFC 2822 indique que le message-id initial doit être repris dans le in-reply-to, mais sans préciser si c'est applicable aux messages d'erreurs. Et encore faut-il pouvoir détecter qu'il s'agit d'un message d'erreur et non d'un message de réponse normal.
La variété des formats pour ce fameux message d'erreur est assez impressionnante :-/
Effectivement. Mais cette variété ne serait pas vraiment gênante si les entêtes suivaient une règle précise :-) Mais existe-t-elle ? Il ne semble pas...
-- Tristan
Fabien LE LEZ <gramster@gramster.com> wrote in message news:<aah7j0hbl0j6r0f03io1g16rptin838bfc@4ax.com>...
On 30 Aug 2004 05:47:06 -0700, Tristan:
Existe-t-il dans les normes relatives à l'e-mail (RFC), quelque chose
qui permette (et qui garantisse) de corréler un e-mail de retour
d'erreur, quelque soit la raison (destinaire inconnu, bal saturée,
...), à l'e-mail initial ?
A priori, la seule piste que je vois serait le message-id du message
original. Mais c'est pas forcément garanti...
Le 1er test que j'ai fait est négatif (bien sûr, il dépend du système
utilisé).
La RFC 2822 indique que le message-id initial doit être repris dans le
in-reply-to, mais sans préciser si c'est applicable aux messages
d'erreurs. Et encore faut-il pouvoir détecter qu'il s'agit d'un
message d'erreur et non d'un message de réponse normal.
La variété des formats pour ce fameux message d'erreur est assez
impressionnante :-/
Effectivement. Mais cette variété ne serait pas vraiment gênante si
les entêtes suivaient une règle précise :-) Mais existe-t-elle ? Il ne
semble pas...
Existe-t-il dans les normes relatives à l'e-mail (RFC), quelque chose qui permette (et qui garantisse) de corréler un e-mail de retour d'erreur, quelque soit la raison (destinaire inconnu, bal saturée, ...), à l'e-mail initial ?
A priori, la seule piste que je vois serait le message-id du message original. Mais c'est pas forcément garanti...
Le 1er test que j'ai fait est négatif (bien sûr, il dépend du système utilisé). La RFC 2822 indique que le message-id initial doit être repris dans le in-reply-to, mais sans préciser si c'est applicable aux messages d'erreurs. Et encore faut-il pouvoir détecter qu'il s'agit d'un message d'erreur et non d'un message de réponse normal.
La variété des formats pour ce fameux message d'erreur est assez impressionnante :-/
Effectivement. Mais cette variété ne serait pas vraiment gênante si les entêtes suivaient une règle précise :-) Mais existe-t-elle ? Il ne semble pas...
-- Tristan
Fabien LE LEZ
On 31 Aug 2004 00:20:43 -0700, (Tristan):
Et encore faut-il pouvoir détecter qu'il s'agit d'un message d'erreur et non d'un message de réponse normal.
Ça, c'est assez facile -- du moins, si tu as un bon client SMTP, et une adresse email spécifique aux messages d'erreurs : il suffit que l'adresse donnée dans la commande SMTP "mail from:" soit différente de l'adresse contenue dans le header "From:" de l'email proprement dit.
Exemple :
... mail from: 250 Sender "" OK... rcpt to: 250 Recipient "" OK... data 354 Enter mail, end with "." on a line by itself From: Tristan To: M. Bidule Subject: un message... ...
De cette manière, la quasi-totalité des messages d'erreurs arrivent sur Il arrive aussi des messages du style "Je suis en vacances", par contre. Et des messages "Warning [...] You don't need to send your message again". Les vraies réponses, par contre, arrivent sur
-- ;-)
On 31 Aug 2004 00:20:43 -0700, 3stan@ifrance.com (Tristan):
Et encore faut-il pouvoir détecter qu'il s'agit d'un
message d'erreur et non d'un message de réponse normal.
Ça, c'est assez facile -- du moins, si tu as un bon client SMTP, et
une adresse email spécifique aux messages d'erreurs : il suffit que
l'adresse donnée dans la commande SMTP "mail from:" soit différente de
l'adresse contenue dans le header "From:" de l'email proprement dit.
Exemple :
...
mail from:<erreurs-3stan@ifrance.com>
250 Sender "erreurs-3stan@ifrance.com" OK...
rcpt to:<machin@truc.com>
250 Recipient "machin@truc.com" OK...
data
354 Enter mail, end with "." on a line by itself
From: Tristan <3stan@ifrance.com>
To: M. Bidule <machin@truc.com>
Subject: un message...
...
De cette manière, la quasi-totalité des messages d'erreurs arrivent
sur erreurs-3stan@ifrance.com. Il arrive aussi des messages du style
"Je suis en vacances", par contre. Et des messages "Warning [...] You
don't need to send your message again".
Les vraies réponses, par contre, arrivent sur 3stan@ifrance.com.
Et encore faut-il pouvoir détecter qu'il s'agit d'un message d'erreur et non d'un message de réponse normal.
Ça, c'est assez facile -- du moins, si tu as un bon client SMTP, et une adresse email spécifique aux messages d'erreurs : il suffit que l'adresse donnée dans la commande SMTP "mail from:" soit différente de l'adresse contenue dans le header "From:" de l'email proprement dit.
Exemple :
... mail from: 250 Sender "" OK... rcpt to: 250 Recipient "" OK... data 354 Enter mail, end with "." on a line by itself From: Tristan To: M. Bidule Subject: un message... ...
De cette manière, la quasi-totalité des messages d'erreurs arrivent sur Il arrive aussi des messages du style "Je suis en vacances", par contre. Et des messages "Warning [...] You don't need to send your message again". Les vraies réponses, par contre, arrivent sur
-- ;-)
3stan
"F. Senault" wrote in message news:<95lgh98p9nsz$...
Existe-t-il dans les normes relatives à l'e-mail (RFC), quelque chose qui permette (et qui garantisse) de corréler un e-mail de retour d'erreur, quelque soit la raison (destinaire inconnu, bal saturée, ...), à l'e-mail initial ? J'ai regardé les RFC 2821 et 2822 et je n'ai rien trouvé (mais ça a pu m'échapper).
Jette déjà un oeil à la RFC 3463 (Enhanced System Status Codes).
J'ai jeté un oeil. Cette RFC élargit les codes retour SMTP (=>ESMTP) pour permettre d'avantage de précision sur l'erreur. Mais ma compréhension est que, comme pour SMTP, ça ne s'applique que pendant la phase synchrone d'envoi du mail. Les retours d'erreurs asynchrones par e-mail à l'émetteur initial ne semblent pas concernés.
-- Tristan
"F. Senault" <fred@lacave.net> wrote in message news:<95lgh98p9nsz$.dlg@ballantines.lacave.local>...
Existe-t-il dans les normes relatives à l'e-mail (RFC), quelque chose
qui permette (et qui garantisse) de corréler un e-mail de retour
d'erreur, quelque soit la raison (destinaire inconnu, bal saturée,
...), à l'e-mail initial ?
J'ai regardé les RFC 2821 et 2822 et je n'ai rien trouvé (mais ça a pu
m'échapper).
Jette déjà un oeil à la RFC 3463 (Enhanced System Status Codes).
J'ai jeté un oeil. Cette RFC élargit les codes retour SMTP (=>ESMTP)
pour permettre d'avantage de précision sur l'erreur. Mais ma
compréhension est que, comme pour SMTP, ça ne s'applique que pendant
la phase synchrone d'envoi du mail. Les retours d'erreurs asynchrones
par e-mail à l'émetteur initial ne semblent pas concernés.
"F. Senault" wrote in message news:<95lgh98p9nsz$...
Existe-t-il dans les normes relatives à l'e-mail (RFC), quelque chose qui permette (et qui garantisse) de corréler un e-mail de retour d'erreur, quelque soit la raison (destinaire inconnu, bal saturée, ...), à l'e-mail initial ? J'ai regardé les RFC 2821 et 2822 et je n'ai rien trouvé (mais ça a pu m'échapper).
Jette déjà un oeil à la RFC 3463 (Enhanced System Status Codes).
J'ai jeté un oeil. Cette RFC élargit les codes retour SMTP (=>ESMTP) pour permettre d'avantage de précision sur l'erreur. Mais ma compréhension est que, comme pour SMTP, ça ne s'applique que pendant la phase synchrone d'envoi du mail. Les retours d'erreurs asynchrones par e-mail à l'émetteur initial ne semblent pas concernés.
