Bonjour, Suite à cette violente vague de spam, nous avons finalement trouvé une parade avec une fonctionnalité que nous traînions à mettre en place : la vérification de l'adresse de l'expéditeur au niveau du dialogue SMTP.
Le but essentiel étant de limiter le nombre de bounces qui restent en queue sur nos serveurs. Si le serveur de l'expéditeur accepte les mails, il se gère le bounce.
OK, ca ne règle pas tout mais en l’occurrence, ça nous a vraiment dégagé une grosse partie de la vague.
MAIS, voilà qu'arrivent les ennuis : ATOS. Une fois par jour, un client a nous reçoit une liste de ces transactions par e-mail.
Le mail a support@e-transactions.fr comme from mais se présente avec une autre adresse dans la transaction SMTP : qmail-smtpd: pid 11718 C: MAIL FROM:ubz@sips-atos.com
Et évidemment, le MX de sips-atos.com ne répond pas sur le port 25 et mail refusé.
Alors la question est : est-ce que j'abuse de filtrer comme ça ou est-ce que je reste droit dans mes bottes et je dis que c'est à Atos de faire le nécessaire ?
Merci de vos commentaires.
Julien
Hello,
Tu risques de rater tous les mails avec les adresses d'expéditeurs fictifs. Par exemple : tous les noreply@
Cordialement, André NEGROPONTES
----- Mail original ----- De: "Julien Escario" escario@azylog.net À: frsag@frsag.org Envoyé: Mardi 21 Juillet 2015 16:03:15 Objet: [FRsAG] Mail from check
Bonjour, Suite à cette violente vague de spam, nous avons finalement trouvé une parade avec une fonctionnalité que nous traînions à mettre en place : la vérification de l'adresse de l'expéditeur au niveau du dialogue SMTP.
Le but essentiel étant de limiter le nombre de bounces qui restent en queue sur nos serveurs. Si le serveur de l'expéditeur accepte les mails, il se gère le bounce.
OK, ca ne règle pas tout mais en l’occurrence, ça nous a vraiment dégagé une grosse partie de la vague.
MAIS, voilà qu'arrivent les ennuis : ATOS. Une fois par jour, un client a nous reçoit une liste de ces transactions par e-mail.
Le mail a support@e-transactions.fr comme from mais se présente avec une autre adresse dans la transaction SMTP : qmail-smtpd: pid 11718 C: MAIL FROM:ubz@sips-atos.com
Et évidemment, le MX de sips-atos.com ne répond pas sur le port 25 et mail refusé.
Alors la question est : est-ce que j'abuse de filtrer comme ça ou est-ce que je reste droit dans mes bottes et je dis que c'est à Atos de faire le nécessaire ?
Merci de vos commentaires.
Julien _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Mets une exception, c'est comme ça depuis des années et atos ne bougera pas.
Guillaume Hilt
Le 21/07/2015 16:03, Julien Escario a écrit :
Bonjour, Suite à cette violente vague de spam, nous avons finalement trouvé une parade avec une fonctionnalité que nous traînions à mettre en place : la vérification de l'adresse de l'expéditeur au niveau du dialogue SMTP.
Le but essentiel étant de limiter le nombre de bounces qui restent en queue sur nos serveurs. Si le serveur de l'expéditeur accepte les mails, il se gère le bounce.
OK, ca ne règle pas tout mais en l’occurrence, ça nous a vraiment dégagé une grosse partie de la vague.
MAIS, voilà qu'arrivent les ennuis : ATOS. Une fois par jour, un client a nous reçoit une liste de ces transactions par e-mail.
Le mail a support@e-transactions.fr comme from mais se présente avec une autre adresse dans la transaction SMTP : qmail-smtpd: pid 11718 C: MAIL FROM:ubz@sips-atos.com
Et évidemment, le MX de sips-atos.com ne répond pas sur le port 25 et mail refusé.
Alors la question est : est-ce que j'abuse de filtrer comme ça ou est-ce que je reste droit dans mes bottes et je dis que c'est à Atos de faire le nécessaire ?
Merci de vos commentaires.
Julien _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Hello,
sauf erreur, c'est du "Sender-Verify" que tu nous fais là. J'aime bien l'explication de Free à ce sujet : http://postmaster.free.fr/#FAQ_Sender_Verify
Je me permet de la recopier ici : « Je veux faire du Sender-Verify !
Le Sender-Verify consiste, lors de la reception d'un mail, à se connecter sur les serveurs MX de l'emetteur et d'aller vérifier que ce dernier existe bien (ou du moins que le serveur accepte bien un mail à destination de son adresse mail). Il s'agit là d'un mécanisme utilisé habituellement comme filtre antispam. Malheureusement, ce mécanisme nous pose différents problêmes.
Pour commencer un peu d'histoire. Il y a une dizaine d'années, la commande SMTP pour vérifier l'existence d'un email ('VRFY') a été d'un commun accord bloquée dans le cadre de la lutte antispam (pour éviter que les spammeurs puisse valider leurs listes). Il nous semble quelque peu paradoxal de voir resurgir dans le cadre de la lutte antispam le principe de vérification d'une boite mail alors que la commande idoine avait été bloquée dans ce même cadre. Par ailleur et du fait de l'absence de cette commande, Sender-Verify simule l'envoi d'un mail pour récuperer le résultat de la commande 'RCPT TO' (la session étant interrompu avant le début de la transmission du mail). Ceci lui permet de voir si le serveur accepte ou refuse une adresse mail comme destinataire. Si à première vue on pourrait considerer qu'il n'y a pas grande différence entre ces deux commandes, il n'en va pas de même au niveau implémentation. Dans un cas, il suffit de vérifier l'existence de la boite, dans l'autre, nous devons vérifier que le mail sera effectivement délivrable (pour éviter d'envoyer des notifications de non délivrance, nous refusons la reception du mail au plus tôt) et ceci a un surcoût en ressources.
Sur un point de vue technique, il ne nous est pas possible de différencier une requete de type Sender-Verify qu'elle provienne d'un spammeur désireux de valider sa liste ou d'un serveur souhaitant vérifier que l'emetteur d'un mail existe bien. Si, à première vue, il peut paraitre souhaitable de pouvoir valider l'existence d'une adresse mail pour rejeter un courier dont l'emetteur n'existerait pas (donc probablement du spam), faire porter à un tiers le coût de ce filtre ne nous semble ni respectueux pour les ressources de celui-ci (alors que les spams représentent la quasi-totalité du traffic et que le domaine usurpé n'a probablement rien à voir avec le spam en question) ni judicieux (dans le cas où il y aurait un spam massif qui usurperait un domaine bien précis, les serveurs en vérifiant les emetteurs risquent fort de participer à l'insu de leur plein gré à une attaque de type DoS à l'encontre du domaine).
De plus, ce filtre est facilement contournable. Il suffit au spammeur d'utiliser une liste d'adresse mail valides pour l'envoi de ses spams. Certains l'utilisent déjà très certainement : certains de nos abonnés se plaignent de recevoir des DSN par centaines (voir milliers). »
Le mardi 21 juillet 2015 à 16:03 +0200, Julien Escario a écrit :
Bonjour, Suite à cette violente vague de spam, nous avons finalement trouvé une parade avec une fonctionnalité que nous traînions à mettre en place : la vérification de l'adresse de l'expéditeur au niveau du dialogue SMTP.
Le but essentiel étant de limiter le nombre de bounces qui restent en queue sur nos serveurs. Si le serveur de l'expéditeur accepte les mails, il se gère le bounce.
OK, ca ne règle pas tout mais en l’occurrence, ça nous a vraiment dégagé une grosse partie de la vague.
MAIS, voilà qu'arrivent les ennuis : ATOS. Une fois par jour, un client a nous reçoit une liste de ces transactions par e-mail.
Le mail a support@e-transactions.fr comme from mais se présente avec une autre adresse dans la transaction SMTP : qmail-smtpd: pid 11718 C: MAIL FROM:ubz@sips-atos.com
Et évidemment, le MX de sips-atos.com ne répond pas sur le port 25 et mail refusé.
Alors la question est : est-ce que j'abuse de filtrer comme ça ou est -ce que je reste droit dans mes bottes et je dis que c'est à Atos de faire le nécessaire ?
Merci de vos commentaires.
Julien _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Le 21/07/2015 16:22, Olivier Bonvalet a écrit :
Hello,
sauf erreur, c'est du "Sender-Verify" que tu nous fais là. J'aime bien l'explication de Free à ce sujet : http://postmaster.free.fr/#FAQ_Sender_Verify
Je me permet de la recopier ici : « Je veux faire du Sender-Verify !
Sur un point de vue technique, il ne nous est pas possible de différencier une requete de type Sender-Verify qu'elle provienne d'un spammeur désireux de valider sa liste ou d'un serveur souhaitant vérifier que l'emetteur d'un mail existe bien. Si, à première vue, il peut paraitre souhaitable de pouvoir valider l'existence d'une adresse mail pour rejeter un courier dont l'emetteur n'existerait pas (donc probablement du spam), faire porter à un tiers le coût de ce filtre ne nous semble ni respectueux pour les ressources de celui-ci (alors que les spams représentent la quasi-totalité du traffic et que le domaine usurpé n'a probablement rien à voir avec le spam en question) ni judicieux (dans le cas où il y aurait un spam massif qui usurperait un domaine bien précis, les serveurs en vérifiant les emetteurs risquent fort de participer à l'insu de leur plein gré à une attaque de type DoS à l'encontre du domaine).
Ah mais au final, ça me va bien ça ! Si ils ne veulent pas supporter le coût du sender-verify, qu'ils commencent donc en place des règles SPF et on les allège du boulot !
Julien
Le 21/07/2015 16:16, Guillaume Hilt a écrit :
Mets une exception, c'est comme ça depuis des années et atos ne bougera pas.
Ce que je viens de faire. Au final, vu le peu de réaction de la liste, on va le garder et on gérera les quelques cas particuliers des mecs qui ne savent pas respecter les bonnes pratiques.
En plus, j'ai l'impression que ca nous fait un peu moins de sp...messages publicitaires en moins. On ne va pas pleurer même si ce n'est pas du spam au sens de la loi.
Merci, Julien
On 21/07/2015 16:03, Julien Escario wrote:
Le mail a support@e-transactions.fr comme from mais se présente avec une autre adresse dans la transaction SMTP : qmail-smtpd: pid 11718 C: MAIL FROM:ubz@sips-atos.com
Comme tous les mails que tu reçois sur cette liste, non ?
Que tu vérifie que le Return-Path annoncé soit capable de traiter un éventuel bounce est une chose, mais vouloir que le MAIL FROM et le From matchent, ca ne me semble pas forcément légitime.
Le 21/07/2015 17:48, Simon Morvan a écrit :
On 21/07/2015 16:03, Julien Escario wrote:
Le mail a support@e-transactions.fr comme from mais se présente avec une autre adresse dans la transaction SMTP : qmail-smtpd: pid 11718 C: MAIL FROM:ubz@sips-atos.com
Comme tous les mails que tu reçois sur cette liste, non ?
Que tu vérifie que le Return-Path annoncé soit capable de traiter un éventuel bounce est une chose, mais vouloir que le MAIL FROM et le From matchent, ca ne me semble pas forcément légitime.
Ah, super remarque, merci !
Effectivement, mon check ne vérifie pas du tout que le return-path et le from soient cohérents. A éviter donc.
Je ne fais qu'une vérification sur la validité du return-path (sur le mail from dans le dialogue smtp plus précisément). Et ça, à priori, les sympas et autres ezmlm font attention que ça réponde correctement.
Julien
21 juillet 2015 17:59 "Julien Escario" escario@azylog.net a écrit:
Je ne fais qu'une vérification sur la validité du return-path (sur le mail from dans le dialogue smtp plus précisément). Et ça, à priori, les sympas et autres ezmlm font attention que ça réponde correctement.
Julien
J'attire sur la possibilité d'être blacklisté si l'on se trouve à vérifier un nombre important d'adresse en peu de temps. En d'autre termes, il faudrait bloquer de ton côté les mauvais éleves avant que ton serveur se fasse blacklister.
Fanch
-
Andre NEGROPONTES -
Fanch -
Guillaume Hilt -
Julien Escario -
Olivier Bonvalet -
Simon Morvan