Voici la question :
Lorsqu'un email est refusé par un serveur, en particulier parce qu'un
fichier attaché est infecté par un virus, est-ce que l'expéditeur et/ou
le destinataire doit(vent) être prévenu(s) ?
Lorsqu'un email est refusé par un serveur, en particulier parce qu'un fichier attaché est infecté par un virus, est-ce que l'expéditeur et/ou le destinataire doit(vent) être prévenu(s) ?
Techniquement, prévenir l'expéditeur est une hérésie, à cause des virus usurpateurs.
Lorsqu'un email est refusé par un serveur, en particulier parce qu'un
fichier attaché est infecté par un virus, est-ce que l'expéditeur et/ou
le destinataire doit(vent) être prévenu(s) ?
Techniquement, prévenir l'expéditeur est une hérésie, à cause des virus
usurpateurs.
Lorsqu'un email est refusé par un serveur, en particulier parce qu'un fichier attaché est infecté par un virus, est-ce que l'expéditeur et/ou le destinataire doit(vent) être prévenu(s) ?
Techniquement, prévenir l'expéditeur est une hérésie, à cause des virus usurpateurs.
Lorsqu'un email est refusé par un serveur, en particulier parce qu'un fichier attaché est infecté par un virus, est-ce que l'expéditeur et/ou le destinataire doit(vent) être prévenu(s) ?
S'il n'est pas prévenu, vous prenez le (gros) risque de détruire une correspondance privée.
Et si vous le prévenez mal (en post-traitement), vous prenez également le risque de (1) ne pas arriver à le joindre (si le bounce est rejeté en face) en étant toujours responsable et/ou (2) spammer un innocent dans la mesure où la plupart des virus maquillent l'émeteur.
La seule et unique option, c'est de rejeter le mail lors de la transaction SMTP. Ne cherchez pas: il n'y a pas d'autre solution fiable documentée par les RFC (*). Toute autre solution est crapouilleuse et non fiable.
Lorsqu'un email est refusé par un serveur, en particulier parce qu'un
fichier attaché est infecté par un virus, est-ce que l'expéditeur et/ou
le destinataire doit(vent) être prévenu(s) ?
S'il n'est pas prévenu, vous prenez le (gros) risque de détruire une
correspondance privée.
Et si vous le prévenez mal (en post-traitement), vous prenez également
le risque de (1) ne pas arriver à le joindre (si le bounce est rejeté en
face) en étant toujours responsable et/ou (2) spammer un innocent dans
la mesure où la plupart des virus maquillent l'émeteur.
La seule et unique option, c'est de rejeter le mail lors de la
transaction SMTP. Ne cherchez pas: il n'y a pas d'autre solution fiable
documentée par les RFC (*). Toute autre solution est crapouilleuse et
non fiable.
Lorsqu'un email est refusé par un serveur, en particulier parce qu'un fichier attaché est infecté par un virus, est-ce que l'expéditeur et/ou le destinataire doit(vent) être prévenu(s) ?
S'il n'est pas prévenu, vous prenez le (gros) risque de détruire une correspondance privée.
Et si vous le prévenez mal (en post-traitement), vous prenez également le risque de (1) ne pas arriver à le joindre (si le bounce est rejeté en face) en étant toujours responsable et/ou (2) spammer un innocent dans la mesure où la plupart des virus maquillent l'émeteur.
La seule et unique option, c'est de rejeter le mail lors de la transaction SMTP. Ne cherchez pas: il n'y a pas d'autre solution fiable documentée par les RFC (*). Toute autre solution est crapouilleuse et non fiable.
Lorsqu'un email est refusé par un serveur, en particulier parce qu'un fichier attaché est infecté par un virus, est-ce que l'expéditeur et/ou le destinataire doit(vent) être prévenu(s) ?
Techniquement, prévenir l'expéditeur est une hérésie, à cause des virus usurpateurs.
Ce n'est pas tout-à-fait vrai. Rejeter un message lors de son arrivée sur le serveur SMTP (ce qui, par le fait, préviendra le vrai expéditeur) est la bonne solution.
Bien entendu, accepter le message puis se baser sur les entêtes pour envoyer un bounce, c'est ça qui est une hérésie (mais malheureusement cela semble plutôt fréquent).
-- Olivier Miakinen Troll du plus sage chez les conviviaux : le nouveau venu, avec son clan, s'infiltre dans les groupes de nouvelles. (3 c.)
Le 26/06/2006 13:32, Patrick Vuichard a écrit :
Lorsqu'un email est refusé par un serveur, en particulier parce qu'un
fichier attaché est infecté par un virus, est-ce que l'expéditeur et/ou
le destinataire doit(vent) être prévenu(s) ?
Techniquement, prévenir l'expéditeur est une hérésie, à cause des virus
usurpateurs.
Ce n'est pas tout-à-fait vrai. Rejeter un message lors de son arrivée
sur le serveur SMTP (ce qui, par le fait, préviendra le vrai expéditeur)
est la bonne solution.
Bien entendu, accepter le message puis se baser sur les entêtes pour
envoyer un bounce, c'est ça qui est une hérésie (mais malheureusement
cela semble plutôt fréquent).
--
Olivier Miakinen
Troll du plus sage chez les conviviaux : le nouveau venu, avec
son clan, s'infiltre dans les groupes de nouvelles. (3 c.)
Lorsqu'un email est refusé par un serveur, en particulier parce qu'un fichier attaché est infecté par un virus, est-ce que l'expéditeur et/ou le destinataire doit(vent) être prévenu(s) ?
Techniquement, prévenir l'expéditeur est une hérésie, à cause des virus usurpateurs.
Ce n'est pas tout-à-fait vrai. Rejeter un message lors de son arrivée sur le serveur SMTP (ce qui, par le fait, préviendra le vrai expéditeur) est la bonne solution.
Bien entendu, accepter le message puis se baser sur les entêtes pour envoyer un bounce, c'est ça qui est une hérésie (mais malheureusement cela semble plutôt fréquent).
-- Olivier Miakinen Troll du plus sage chez les conviviaux : le nouveau venu, avec son clan, s'infiltre dans les groupes de nouvelles. (3 c.)
Xavier Roche
Olivier Miakinen a écrit :
Bien entendu, accepter le message puis se baser sur les entêtes pour envoyer un bounce, c'est ça qui est une hérésie (mais malheureusement cela semble plutôt fréquent).
Ce n'est pas tellement le problème de se baser sur les en-têtes (ou l'enveloppe), mais d'accepter en premier lieu la responsabilité de la livraison du message sans avoir d'informations complémentaires sur le contenu et/ou le destinataire.
Un peu comme accepter que quelqun vous donne un colis dans la rue, et seulement après être rentré chez vous, vous demander "au fait, (1) est-ce bien pour moi et (2) est-ce un colis piégé ?"
Olivier Miakinen a écrit :
Bien entendu, accepter le message puis se baser sur les entêtes pour
envoyer un bounce, c'est ça qui est une hérésie (mais malheureusement
cela semble plutôt fréquent).
Ce n'est pas tellement le problème de se baser sur les en-têtes (ou
l'enveloppe), mais d'accepter en premier lieu la responsabilité de la
livraison du message sans avoir d'informations complémentaires sur le
contenu et/ou le destinataire.
Un peu comme accepter que quelqun vous donne un colis dans la rue, et
seulement après être rentré chez vous, vous demander "au fait, (1)
est-ce bien pour moi et (2) est-ce un colis piégé ?"
Bien entendu, accepter le message puis se baser sur les entêtes pour envoyer un bounce, c'est ça qui est une hérésie (mais malheureusement cela semble plutôt fréquent).
Ce n'est pas tellement le problème de se baser sur les en-têtes (ou l'enveloppe), mais d'accepter en premier lieu la responsabilité de la livraison du message sans avoir d'informations complémentaires sur le contenu et/ou le destinataire.
Un peu comme accepter que quelqun vous donne un colis dans la rue, et seulement après être rentré chez vous, vous demander "au fait, (1) est-ce bien pour moi et (2) est-ce un colis piégé ?"
Le GBAHB
On Mon, 26 Jun 2006 13:29:43 +0200, "Remy.Claverie" wrote:
Bonjour à tous,
Bonjour !
Voici la question : Lorsqu'un email est refusé par un serveur, en particulier parce qu'un fichier attaché est infecté par un virus, est-ce que l'expéditeur et/ou le destinataire doit(vent) être prévenu(s) ?
Au sens juridique : non, il n'y a aucune obligation.
De même que La Poste n'a pas juridiquement obligation de vous prévenir si le courrier qui vous était destiné a disparu pour une raison ou une autre indépendante de sa volonté (incendie, inondation, perte, vol, évaporation, etc.), pour la simple raison qu'elle ne tient pas à jour un registre courant du trafic standard (i.e. pas d'enregistrement de chaque lettre, missive, paquet, etc. envoyé en trafic normal).
Existe t-il une jurisprudence en la matière ?
A ma connaissance, non. Le trafic e-mail ne relève en tout bon sens d'aucune jurisprudence puisque le protocole SMTP ne *garantit PAS* la livraison en temps, en heure ou en lieu du message envoyé (d'autant plus que le trafic est international et que L'Union Postale Internationale n'est pas concernée par le trafic SMTP).
Pour garantir la réception du matériel, vous pouvez utiliser, à l'image des protocoles utilisés par La Poste et d'autres achemineurs de courrier, de protocoles plus fiables et mieux garantis :
- Courrier terrestre : colis inscrit, envoit recommandé / recommandé avec AR, etc. La responsabilité de La Poste est engagée au niveau de l'envoi.
- Courrier électronique : certaines sociétés sont habilitées à certifier (y compris devant les Tribunaux) que l'envoi est bien parvenu à son destinataire (avec preuve de l'authenticité de l'envoi), telles
en France, qui s'engagent également à contrôler et certifier la distribution.
Merci
A votre service.
On Mon, 26 Jun 2006 13:29:43 +0200, "Remy.Claverie"
<claverie@univ-metz.fr> wrote:
Bonjour à tous,
Bonjour !
Voici la question :
Lorsqu'un email est refusé par un serveur, en particulier parce qu'un
fichier attaché est infecté par un virus, est-ce que l'expéditeur et/ou
le destinataire doit(vent) être prévenu(s) ?
Au sens juridique : non, il n'y a aucune obligation.
De même que La Poste n'a pas juridiquement obligation de vous prévenir
si le courrier qui vous était destiné a disparu pour une raison ou une
autre indépendante de sa volonté (incendie, inondation, perte, vol,
évaporation, etc.), pour la simple raison qu'elle ne tient pas à jour
un registre courant du trafic standard (i.e. pas d'enregistrement de
chaque lettre, missive, paquet, etc. envoyé en trafic normal).
Existe t-il une jurisprudence en la matière ?
A ma connaissance, non. Le trafic e-mail ne relève en tout bon sens
d'aucune jurisprudence puisque le protocole SMTP ne *garantit PAS* la
livraison en temps, en heure ou en lieu du message envoyé (d'autant
plus que le trafic est international et que L'Union Postale
Internationale n'est pas concernée par le trafic SMTP).
Pour garantir la réception du matériel, vous pouvez utiliser, à
l'image des protocoles utilisés par La Poste et d'autres achemineurs
de courrier, de protocoles plus fiables et mieux garantis :
- Courrier terrestre : colis inscrit, envoit recommandé / recommandé
avec AR, etc. La responsabilité de La Poste est engagée au niveau de
l'envoi.
- Courrier électronique : certaines sociétés sont habilitées à
certifier (y compris devant les Tribunaux) que l'envoi est bien
parvenu à son destinataire (avec preuve de l'authenticité de l'envoi),
telles
On Mon, 26 Jun 2006 13:29:43 +0200, "Remy.Claverie" wrote:
Bonjour à tous,
Bonjour !
Voici la question : Lorsqu'un email est refusé par un serveur, en particulier parce qu'un fichier attaché est infecté par un virus, est-ce que l'expéditeur et/ou le destinataire doit(vent) être prévenu(s) ?
Au sens juridique : non, il n'y a aucune obligation.
De même que La Poste n'a pas juridiquement obligation de vous prévenir si le courrier qui vous était destiné a disparu pour une raison ou une autre indépendante de sa volonté (incendie, inondation, perte, vol, évaporation, etc.), pour la simple raison qu'elle ne tient pas à jour un registre courant du trafic standard (i.e. pas d'enregistrement de chaque lettre, missive, paquet, etc. envoyé en trafic normal).
Existe t-il une jurisprudence en la matière ?
A ma connaissance, non. Le trafic e-mail ne relève en tout bon sens d'aucune jurisprudence puisque le protocole SMTP ne *garantit PAS* la livraison en temps, en heure ou en lieu du message envoyé (d'autant plus que le trafic est international et que L'Union Postale Internationale n'est pas concernée par le trafic SMTP).
Pour garantir la réception du matériel, vous pouvez utiliser, à l'image des protocoles utilisés par La Poste et d'autres achemineurs de courrier, de protocoles plus fiables et mieux garantis :
- Courrier terrestre : colis inscrit, envoit recommandé / recommandé avec AR, etc. La responsabilité de La Poste est engagée au niveau de l'envoi.
- Courrier électronique : certaines sociétés sont habilitées à certifier (y compris devant les Tribunaux) que l'envoi est bien parvenu à son destinataire (avec preuve de l'authenticité de l'envoi), telles
en France, qui s'engagent également à contrôler et certifier la distribution.
Merci
A votre service.
Olivier Miakinen
Le 26/06/2006 14:36, Xavier Roche a écrit :
Bien entendu, accepter le message puis se baser sur les entêtes pour envoyer un bounce, c'est ça qui est une hérésie (mais malheureusement cela semble plutôt fréquent).
Ce n'est pas tellement le problème de se baser sur les en-têtes (ou l'enveloppe), mais d'accepter en premier lieu la responsabilité de la livraison du message sans avoir d'informations complémentaires sur le contenu et/ou le destinataire.
C'est bien là qu'est la toute première faute, en effet. Mais quand elle est doublée par un bounce après coup, je trouve que c'est encore pire -- et encore une fois il y a des serveurs qui cumulent les deux.
Un peu comme accepter que quelqun vous donne un colis dans la rue, et seulement après être rentré chez vous, vous demander "au fait, (1) est-ce bien pour moi et (2) est-ce un colis piégé ?"
Jolie MÀLC !
-- Olivier Miakinen Troll du plus sage chez les conviviaux : le nouveau venu, avec son clan, s'infiltre dans les groupes de nouvelles. (3 c.)
Le 26/06/2006 14:36, Xavier Roche a écrit :
Bien entendu, accepter le message puis se baser sur les entêtes pour
envoyer un bounce, c'est ça qui est une hérésie (mais malheureusement
cela semble plutôt fréquent).
Ce n'est pas tellement le problème de se baser sur les en-têtes (ou
l'enveloppe), mais d'accepter en premier lieu la responsabilité de la
livraison du message sans avoir d'informations complémentaires sur le
contenu et/ou le destinataire.
C'est bien là qu'est la toute première faute, en effet. Mais quand elle
est doublée par un bounce après coup, je trouve que c'est encore pire --
et encore une fois il y a des serveurs qui cumulent les deux.
Un peu comme accepter que quelqun vous donne un colis dans la rue, et
seulement après être rentré chez vous, vous demander "au fait, (1)
est-ce bien pour moi et (2) est-ce un colis piégé ?"
Jolie MÀLC !
--
Olivier Miakinen
Troll du plus sage chez les conviviaux : le nouveau venu, avec
son clan, s'infiltre dans les groupes de nouvelles. (3 c.)
Bien entendu, accepter le message puis se baser sur les entêtes pour envoyer un bounce, c'est ça qui est une hérésie (mais malheureusement cela semble plutôt fréquent).
Ce n'est pas tellement le problème de se baser sur les en-têtes (ou l'enveloppe), mais d'accepter en premier lieu la responsabilité de la livraison du message sans avoir d'informations complémentaires sur le contenu et/ou le destinataire.
C'est bien là qu'est la toute première faute, en effet. Mais quand elle est doublée par un bounce après coup, je trouve que c'est encore pire -- et encore une fois il y a des serveurs qui cumulent les deux.
Un peu comme accepter que quelqun vous donne un colis dans la rue, et seulement après être rentré chez vous, vous demander "au fait, (1) est-ce bien pour moi et (2) est-ce un colis piégé ?"
Jolie MÀLC !
-- Olivier Miakinen Troll du plus sage chez les conviviaux : le nouveau venu, avec son clan, s'infiltre dans les groupes de nouvelles. (3 c.)
Patrick Vuichard
Olivier Miakinen a écrit, le 26/06/2006 14:33 :
Techniquement, prévenir l'expéditeur est une hérésie, à cause des virus usurpateurs.
Ce n'est pas tout-à-fait vrai. Rejeter un message lors de son arrivée sur le serveur SMTP (ce qui, par le fait, préviendra le vrai expéditeur) est la bonne solution.
Tout à fait. Mais là, je pense que la question est au niveau du serveur du destinataire.
Bien entendu, accepter le message puis se baser sur les entêtes pour envoyer un bounce, c'est ça qui est une hérésie (mais malheureusement cela semble plutôt fréquent).
Il faudrait pendre par les orteils les "admins" qui configurent comme ça.
Techniquement, prévenir l'expéditeur est une hérésie, à cause des virus
usurpateurs.
Ce n'est pas tout-à-fait vrai. Rejeter un message lors de son arrivée
sur le serveur SMTP (ce qui, par le fait, préviendra le vrai expéditeur)
est la bonne solution.
Tout à fait. Mais là, je pense que la question est au niveau du serveur
du destinataire.
Bien entendu, accepter le message puis se baser sur les entêtes pour
envoyer un bounce, c'est ça qui est une hérésie (mais malheureusement
cela semble plutôt fréquent).
Il faudrait pendre par les orteils les "admins" qui configurent comme ça.
Techniquement, prévenir l'expéditeur est une hérésie, à cause des virus usurpateurs.
Ce n'est pas tout-à-fait vrai. Rejeter un message lors de son arrivée sur le serveur SMTP (ce qui, par le fait, préviendra le vrai expéditeur) est la bonne solution.
Tout à fait. Mais là, je pense que la question est au niveau du serveur du destinataire.
Bien entendu, accepter le message puis se baser sur les entêtes pour envoyer un bounce, c'est ça qui est une hérésie (mais malheureusement cela semble plutôt fréquent).
Il faudrait pendre par les orteils les "admins" qui configurent comme ça.
