assistance du protocole SMTP pour la lutte antispam et antivirale
3 réponses
Brieuc Jeunhomme
Bonjour,
je me pose une question sur la manière dont SMTP pourrait contribuer
à réduire les nuisances dues aux virus et aux spams. En ce qui me
concerne, je reçois chaque jour environ une centaine de bounces de MTAs
m'informant qu'une adresse vers laquelle je n'ai jamais posté n'existe
plus ou n'a jamais existé. Etant donné que j'utilise un MUA sous linux,
je ne pense pas être si vérolé que ça, et d'ailleurs, les logs du
serveur mail ne comportent aucune trace de ces mails que j'aurais
envoyés.
Autrement dit, ces mails sont envoyés par des tierces parties, et donc,
j'aimerais bien ne pas recevoir les bounces, ou disposer d'un moyen pour
que mon MUA les élimine automatiquement, tout en conservant les vrais
bounces, c'est-à-dire ceux qui viennent de mes multiples typos. J'ai
cherché des solutions à ce problème, mais je n'en ai pas trouvé sur le
net, ni même de discussions à ce sujet.
Pourtant, je pense qu'un premier pas, très simple, serait que quand
un serveur SMTP envoie un bounce, il ajoute un header indiquant qu'il
s'agit d'un bounce et contenant le Message-ID du mail bouncé. De cette
manière, le MUA pourrait faire le tri et regarder s'il a effectivement
envoyé un message avec cet ID. Dans le cas contraire, il pourrait
l'éliminer.
Je suis conscient que ce n'est pas idéal, dans la mesure où ça
obligerait le MUA à parcourir une liste éventuellement longue de
messages envoyés, mais il y a des alternatives qui me paraissent tout
aussi simples et pratiques.
Par exemple, que dans chaque message que j'envoie, mon MUA ajoute un
header contenant un nombre qui me serait propre (par exemple généré
aléatoirement à l'envoi du premier message), et que le SMTP destinataire
élimine ce header au moment où il délivre le message, de sorte que
même si la machine du destinataire est vérolée, il n'ait pas accès à
ce nombre. Par contre, au cas où je me serais trompé d'adresse, le
bounce pourrait contenir un header indiquant qu'il s'agit d'un bounce,
et donnant ce nombre qui me serait propre. Ainsi, quand je recevrais
des bounces n'ayant rien à faire dans ma mailbox, mon MUA pourrait les
éliminer. Naturellement, cette solution pose le problème d'associer un
nombre à chaque personne, protection de la vie privée, etc etc, mais si
l'intervalle de choix de ces nombres est suffisament restreint, disons
des nombres variant entre 0 et 999, ça diviserait déjà par 1000 le
nombre de bounces n'ayant rien à voir avec moi et ne permettrait pas
pour autant d'associer un numéro à chaque personne.
J'imagine que cette question a probablement déjà été discutée, mais je
suis curieux de connaître les raisons pour lesquelles ce type de
solutions n'a pas été retenu.
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
Eric Demeester
dans (in) fr.comp.mail, Brieuc Jeunhomme ecrivait (wrote) :
Bonsoir Brieuc,
je me pose une question sur la manière dont SMTP pourrait contribuer à réduire les nuisances dues aux virus et aux spams. En ce qui me concerne, je reçois chaque jour environ une centaine de bounces de MTAs m'informant qu'une adresse vers laquelle je n'ai jamais posté n'existe plus ou n'a jamais existé.
Je suis dans le même cas et en résumé, on n'y peut rien.
Autrement dit, ces mails sont envoyés par des tierces parties, et donc, j'aimerais bien ne pas recevoir les bounces,
Dans la mesure ou les mails en question (des virus probablement) ont été envoyés en mettant votre adresse dans le From: , il est logique que vous receviez les bounces.
Pourtant, je pense qu'un premier pas, très simple, serait que quand un serveur SMTP envoie un bounce, il ajoute un header indiquant qu'il s'agit d'un bounce et contenant le Message-ID du mail bouncé.
Les serveurs bien configurés le font automatiquement, mais malheureusement, ils sont peu nombreux (voire inexistants sous Windows).
J'imagine que cette question a probablement déjà été discutée, mais je suis curieux de connaître les raisons pour lesquelles ce type de solutions n'a pas été retenu.
Parce qu'on ne peut pratiquement rien faire quand on cause à des serveurs sous Windows, et que ces cochonneries sont de plus en plus envahissantes.
-- Eric
dans (in) fr.comp.mail, Brieuc Jeunhomme <bbp@via.ecp.fr> ecrivait
(wrote) :
Bonsoir Brieuc,
je me pose une question sur la manière dont SMTP pourrait contribuer
à réduire les nuisances dues aux virus et aux spams. En ce qui me
concerne, je reçois chaque jour environ une centaine de bounces de MTAs
m'informant qu'une adresse vers laquelle je n'ai jamais posté n'existe
plus ou n'a jamais existé.
Je suis dans le même cas et en résumé, on n'y peut rien.
Autrement dit, ces mails sont envoyés par des tierces parties, et donc,
j'aimerais bien ne pas recevoir les bounces,
Dans la mesure ou les mails en question (des virus probablement) ont été
envoyés en mettant votre adresse dans le From: , il est logique que vous
receviez les bounces.
Pourtant, je pense qu'un premier pas, très simple, serait que quand
un serveur SMTP envoie un bounce, il ajoute un header indiquant qu'il
s'agit d'un bounce et contenant le Message-ID du mail bouncé.
Les serveurs bien configurés le font automatiquement, mais
malheureusement, ils sont peu nombreux (voire inexistants sous Windows).
J'imagine que cette question a probablement déjà été discutée, mais je
suis curieux de connaître les raisons pour lesquelles ce type de
solutions n'a pas été retenu.
Parce qu'on ne peut pratiquement rien faire quand on cause à des
serveurs sous Windows, et que ces cochonneries sont de plus en plus
envahissantes.
dans (in) fr.comp.mail, Brieuc Jeunhomme ecrivait (wrote) :
Bonsoir Brieuc,
je me pose une question sur la manière dont SMTP pourrait contribuer à réduire les nuisances dues aux virus et aux spams. En ce qui me concerne, je reçois chaque jour environ une centaine de bounces de MTAs m'informant qu'une adresse vers laquelle je n'ai jamais posté n'existe plus ou n'a jamais existé.
Je suis dans le même cas et en résumé, on n'y peut rien.
Autrement dit, ces mails sont envoyés par des tierces parties, et donc, j'aimerais bien ne pas recevoir les bounces,
Dans la mesure ou les mails en question (des virus probablement) ont été envoyés en mettant votre adresse dans le From: , il est logique que vous receviez les bounces.
Pourtant, je pense qu'un premier pas, très simple, serait que quand un serveur SMTP envoie un bounce, il ajoute un header indiquant qu'il s'agit d'un bounce et contenant le Message-ID du mail bouncé.
Les serveurs bien configurés le font automatiquement, mais malheureusement, ils sont peu nombreux (voire inexistants sous Windows).
J'imagine que cette question a probablement déjà été discutée, mais je suis curieux de connaître les raisons pour lesquelles ce type de solutions n'a pas été retenu.
Parce qu'on ne peut pratiquement rien faire quand on cause à des serveurs sous Windows, et que ces cochonneries sont de plus en plus envahissantes.
j'aimerais bien ne pas recevoir les bounces, [...] tout en conservant les vrais bounces, c'est-à-dire ceux qui viennent de mes multiples typos.
Un envoi d'email se passe de la façon suivante :
salutations d'usage (ehlo ou helo) mail from:<expediteur1> rcpt to:<destinataire1> data From: <expediteur2> To: <expediteur2> etc.
L'expéditeur vu par le lecteur de courrier du destinataire final est expediteur2, tandis que l'expéditeur vu par les serveurs SMTP successifs est expediteur1. A priori, il n'y a pas de raison pour que expediteur1 et expediteur2 soient égaux. expediteur2 est ton adresse email, tandis que expediteur1 peut être une adresse style
Ainsi, tous les bounce iront vers ; un bounce qui arrive sur est vraisemblablement un faux.
Note: un bounce est un email dans lequel "expediteur1" est vide.
j'aimerais bien ne pas recevoir les bounces, [...] tout en conservant les vrais
bounces, c'est-à-dire ceux qui viennent de mes multiples typos.
Un envoi d'email se passe de la façon suivante :
salutations d'usage (ehlo ou helo)
mail from:<expediteur1>
rcpt to:<destinataire1>
data
From: <expediteur2>
To: <expediteur2>
etc.
L'expéditeur vu par le lecteur de courrier du destinataire final est
expediteur2, tandis que l'expéditeur vu par les serveurs SMTP
successifs est expediteur1.
A priori, il n'y a pas de raison pour que expediteur1 et expediteur2
soient égaux. expediteur2 est ton adresse email, tandis que
expediteur1 peut être une adresse style bbp_erreurs@via.ecp.fr.
Ainsi, tous les bounce iront vers bbp_erreurs@via.ecp.fr; un bounce
qui arrive sur bbp@via.ecp.fr est vraisemblablement un faux.
Note: un bounce est un email dans lequel "expediteur1" est vide.
j'aimerais bien ne pas recevoir les bounces, [...] tout en conservant les vrais bounces, c'est-à-dire ceux qui viennent de mes multiples typos.
Un envoi d'email se passe de la façon suivante :
salutations d'usage (ehlo ou helo) mail from:<expediteur1> rcpt to:<destinataire1> data From: <expediteur2> To: <expediteur2> etc.
L'expéditeur vu par le lecteur de courrier du destinataire final est expediteur2, tandis que l'expéditeur vu par les serveurs SMTP successifs est expediteur1. A priori, il n'y a pas de raison pour que expediteur1 et expediteur2 soient égaux. expediteur2 est ton adresse email, tandis que expediteur1 peut être une adresse style
Ainsi, tous les bounce iront vers ; un bounce qui arrive sur est vraisemblablement un faux.
Note: un bounce est un email dans lequel "expediteur1" est vide.
Pourtant, je pense qu'un premier pas, très simple, serait que quand un serveur SMTP envoie un bounce, il ajoute un header indiquant qu'il s'agit d'un bounce et contenant le Message-ID du mail bouncé. De cette manière, le MUA pourrait faire le tri et regarder s'il a effectivement envoyé un message avec cet ID. Dans le cas contraire, il pourrait l'éliminer.
Quelques idées:
Beaucoup de bounces contiennent les en-têtes du mail d'origine (voire tout son texte). Tu peux t'en servir pour comparer avec ce que tu as envoyé dans les derniers jours.
Les serveurs qui ne reprennent pas l'intégralité des en-têtes remettent souvent le To: et/ou le Subject: ; là encore, tu peux t'en servir, même si ce sera moins fiable.
Encore moins fiable, mais très facile à exploiter: tu peux regarder si tu as déjà envoyé un mail au domaine auquel appartient le serveur qui prétend te répondre.
A priori, tu peux éliminer les bounces qui t'accusent d'avoir envoyé un virus (fais-toi une petite base des noms de virus).
Avec ces quelques idées, tu dois déjà pouvoir filtrer pas mal de ta pollution. Ça vaut le coup d'écrire quelques lignes de Perl pour faire ce travail.
Pourtant, je pense qu'un premier pas, très simple, serait que quand
un serveur SMTP envoie un bounce, il ajoute un header indiquant qu'il
s'agit d'un bounce et contenant le Message-ID du mail bouncé. De cette
manière, le MUA pourrait faire le tri et regarder s'il a effectivement
envoyé un message avec cet ID. Dans le cas contraire, il pourrait
l'éliminer.
Quelques idées:
Beaucoup de bounces contiennent les en-têtes du mail d'origine (voire
tout son texte). Tu peux t'en servir pour comparer avec ce que tu as
envoyé dans les derniers jours.
Les serveurs qui ne reprennent pas l'intégralité des en-têtes
remettent souvent le To: et/ou le Subject: ; là encore, tu peux t'en
servir, même si ce sera moins fiable.
Encore moins fiable, mais très facile à exploiter: tu peux regarder si
tu as déjà envoyé un mail au domaine auquel appartient le serveur qui
prétend te répondre.
A priori, tu peux éliminer les bounces qui t'accusent d'avoir envoyé
un virus (fais-toi une petite base des noms de virus).
Avec ces quelques idées, tu dois déjà pouvoir filtrer pas mal de ta
pollution. Ça vaut le coup d'écrire quelques lignes de Perl pour faire
ce travail.
Pourtant, je pense qu'un premier pas, très simple, serait que quand un serveur SMTP envoie un bounce, il ajoute un header indiquant qu'il s'agit d'un bounce et contenant le Message-ID du mail bouncé. De cette manière, le MUA pourrait faire le tri et regarder s'il a effectivement envoyé un message avec cet ID. Dans le cas contraire, il pourrait l'éliminer.
Quelques idées:
Beaucoup de bounces contiennent les en-têtes du mail d'origine (voire tout son texte). Tu peux t'en servir pour comparer avec ce que tu as envoyé dans les derniers jours.
Les serveurs qui ne reprennent pas l'intégralité des en-têtes remettent souvent le To: et/ou le Subject: ; là encore, tu peux t'en servir, même si ce sera moins fiable.
Encore moins fiable, mais très facile à exploiter: tu peux regarder si tu as déjà envoyé un mail au domaine auquel appartient le serveur qui prétend te répondre.
A priori, tu peux éliminer les bounces qui t'accusent d'avoir envoyé un virus (fais-toi une petite base des noms de virus).
Avec ces quelques idées, tu dois déjà pouvoir filtrer pas mal de ta pollution. Ça vaut le coup d'écrire quelques lignes de Perl pour faire ce travail.
