Vous êtes sans doute sur cette page car vous avez eu un problème pour envoyer du mail à nos abonnés Free.fr. Sur cette page, vous trouverez les explications et les solutions à apporter à votre solution de messagerie pour lutter avec nous contre le spam.

Le formulaire suivant vous permettra de vérifier si votre IP est listée chez nous :

La durée de blocage dépend du nombre de spams ou d’erreurs que vous avez généré, la durée maximale du blocage est de 24h. Passé ce delai votre IP sera automatiquement débloquée.

Attention : si votre serveur continue d’essayer d'envoyer du spam vous serez à nouveau bloqué. Il est donc inutile de demander à être déblacklisté tant que le probleme responsable du blocage n'a pas été résolu.

Les décisions de blocages sont prises en se basant sur des statistiques que nous maintenons en temps réel pour chaque IP qui s'est connecté sur nos serveurs MX et sur une analyse des logs. Il est possible, qu'après résolution d'un problême, vous soyez à nouveau blacklisté dans les 24 à 48 heures ; il s'agit là du délai moyen necessaire pour que les anciennes statistiques deviennent négligeables.

Il y a plusieurs raisons qui peuvent nous pousser à bloquer une IP. Pour chacune de ces raisons nos serveurs renvoient des messages d’erreurs différents qui sont listés ci-dessous, vous trouverez ce message d’erreur dans les fichiers de logs de votre serveur SMTP ou dans un DSN que votre relais vous aura renvoyé :

Vous avez cette erreur car le mail que vous avez envoyé a été analysé comme étant un spam par notre filtre antispam et il a été refusé lors de la reception. La notification a été généré par le serveur SMTP que vous utilisez ou, s'il ne s'agit pas d'un mail que vous auriez envoyé, par le serveur SMTP utilisé par la personne qui a usurpé votre adresse email.

Il peut être utile de commencer par vérifier que votre mail ne soit pas susceptible d'être confondu avec un spam, que ce soit en utilisant un logiciel antispam ou en vérifiant que votre mail est syntaxiquement correct et que vous n'utilisez pas de mécanismes qui puissent être confondus avec certaines méthodes de spammeurs.

Le cas échéant, nous vous invitons à nous signaler un faux positif en suivant cette procédure.

Vous avez cette erreur car votre serveur a envoyé trop de spams au abonnés Free.fr, le serveur a donc pris la décision de ne plus accepter les connexions venant de votre serveur SMTP de façon temporaire.

Votre adresse IP sera automatiquement retirée de la liste noire temporaire au bout de 24 heures maximum.

• Si vous avez votre propre serveur SMTP : en attendant l'expiration de ce delai nous vous conseillons de mettre en place un filtre antispam vous permettant de ne plus envoyer/relayer/forwarder de spams vers nos serveurs

• Si vous utilisez un relais SMTP : contacter au plus vite votre prestataire pour qu'il prenne les mesures appropriées pour ne plus etre bloqué à l'avenir.

Vous avez ce message car votre serveur SMTP a généré un nombre d'erreurs trop important lors du dialogue avec les serveurs de Free.fr (typiquement des connexions interrompues avant la bonne transmission d'un mail). Il est également possible que le comportement de votre serveur nous laisse l'impression d'être sous le coup d'une attaque dictionnaire (qu'il s'agisse d'envoi de mails ou de validation d'email). Votre IP a donc été bloqué temporairement.

• Si vous avez votre propre serveur SMTP : en attendant l'expiration de ce delai nous vous conseillons de vérifier votre configuration (êtes vous relais ouvert ?). Si vous utilisez la technique “Sender Verify” qui consiste à se connecter sur nos serveurs pour vérifier que le mail from qu'on vous a donné est bien valide nous vous conseillons de désactiver cette fonctionnalité. Il est également possible que votre serveur renvoie des notifications automatiques (mail non délivrable, autorépondeur, etc.) sur du spam. Dans ce cas, il est conseillé de refuser les mails au plus tôt (lors de la reception) pour éviter d'avoir à générer des notifications de mail non délivrable et/ou de s'abstenir de faire des réponses automatique sur les mails qui sont detectés comme étant des spams.

• Si vous utilisez un relais SMTP : contactez au plus vite votre prestataire pour qu'il prenne les mesures appropriées pour ne plus etre bloqué à l'avenir.

Votre IP n'est pas encore bloquée, mais nous n'acceptons plus les mails du fait d'un trop grand nombre d'erreurs. Si votre serveur continue de générer des erreurs vous serez bloqué pour une durée supérieur (et vous aurez une erreur 500).

• Si vous avez votre propre serveur SMTP : en attendant l'expiration de ce delai nous vous conseillons de vérifier votre configuration (êtes vous relais ouvert ?). Si vous utilisez la technique “Sender Verify” nous vous conseillons de la désactiver (analysée par nos serveurs comme une attaque dictionnaire). Il est également possible que votre serveur renvoie des notifications automatiques (mail non délivrable, autorépondeur, etc.) sur du spam. Dans ce cas, il est conseillé de refuser les mails au plus tôt (lors de la reception) pour éviter d'avoir à générer des notifications de mail non délivrable et/ou de s'abstenir de faire des réponses automatique sur les mails qui sont detectés comme étant des spams.

• Si vous utilisez un relais SMTP : contactez au plus vite votre prestataire pour qu'il prenne les mesures appropriées pour ne plus etre bloqué à l'avenir.

Non, nous n'utilisons que des données internes pour bloquer une adresse IP.

24 heures maximum, vous pouvez utiliser cet outil pour voir si votre adresse IP est listée et pour combien de temps.

Historiquement, les mails non sollicités (spams, virus, etc.) étaient principalement une gêne pour les utilisateurs obligés de faire le tri à la main pour séparer le bon grain de l'ivraie. Aujourd'hui, la volumétrie générée par les mails non sollicités est telle qu'elle pose de sérieux problemes techniques sur l'hebergement d'une plateforme mail.

Pour le mois de décembre 2007, une étude a conclu à la présence de 97.13% de mails non sollicités dans les mails reçus. Cela signifie que pour gerer les spams indifférement des mails, il aurait fallu surdimensionner une plateforme mail d'un facteur 34 (33.84 pour être précis) et cela commence à devenir difficilement gérable. Cela impacte l'ensemble des serveurs concernés par l'hebergement mail, qu'il s'agisse de la reception (les serveurs MX), le stockage (aussi bien en terme d'espace de stockage que de la charge en IO) et la retransmission vers les utilisateurs (serveurs POP et IMAP).

Pour les mois de décembre 2006 et décembre 2005, des études équivalentes avaient conclus à la présence d'environ 95% et 90% de spams dans le traffic mail reçu (d'une étude à l'autre, les chiffres varient). La croissance du traffic mail non sollicité progresse peu ou prou deux fois plus vitre que le traffic mail légitime ces dernières années et il est illusoire d'esperer continuer à gérer une plateforme d'hebergement mail un tant soit peu conséquente. Le traffic mail généré par les spams et autres mails non sollicités constituent désormais l'équivalent d'une attaque permanente contre les plateforme d'hebergement mail.

Nous nous sommes donc trouvés dans l'obligation de mettre en place un filtrage dit "antispam". Malheureusement, s'il protege plus ou moins efficacement la partie stockage et délivrance vers les utilisateurs, les serveurs de reception restent sous le feu de la volumétrie et il nous aurait fallu prévoir plus du doublement de leur capacité de reception/filtrage chaque année. Bref, nous continuions d'avoir besoin de dimensionner une partie de l'architecture mail au même rythme que le traffic de mails non sollicités.

Pour finir, la manière dont les spams sont envoyés rendaient nos serveurs MX inaccessibles. En passant majoritairement via des PCs vérolés derrière des connexions “lentes“ (connexions RTC, ADSL, RNIS, etc. de simples utilisateurs ou au travers de connexions internationnales saturées), le temps moyen de connexion s'allonge et les connexions se multiplient en saturant les serveurs. Comme les spammeurs sont également agressifs sur les ouvertures de connexions, non seulement nos serveurs étaient difficilement accessibles mais avec un net déséquilibre en défaveur des serveurs “légitimes“.

C'est pour sortir de ce cercle vicieux que nous avons décidé de bloquer les IPs dont le traffic reçu comportait une part importante de spam (les regles actuelles bloquent lorsque nous recevons plus de mails détectés comme spams que de mails "normaux"), dont le comportement était atypique (nombreuses connexions coupées, nombreux destinataires inexistants, etc.) ou abusif (validation d'adresses mails, mail-bombing, etc.).

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).

S'il est normal d'informer un utilisateur que son mail n'a pu être transmis à son destinataire ou que untel est en congé, il ne faut pas non plus en envoyer à tort et à travers. Alors que le traffic mail est composé dans sa quasi-totalité de spams (dont les emetteurs sont usurpés), envoyer une notification automatique est un exercice périlleux car les risques d'envoyer un mail non sollicité sont elevés (si l'emetteur est usurpé, la notification est envoyé à un destinataire qui n'a strictement rien demandé et se transforme donc en mail non sollicité au même titre que les spams). Il est donc souhaitable de refuser au plus tôt un mail (typiquement lors du dialogue SMTP sur le 'RCPT TO' dans le cadre où un destinataire serait inexistant ou ne pourrait recevoir de mail, sur la fin du 'DATA' dans le cas où vous décideriez de refuser le mail) voir s'abstenir d'envoyer de notification automatique si le mail semble être un spam. Ceci aurait en plus l'interet de réduire sensiblement le traffic mail puisque les spammeurs s'abstiennent généralement d'emettre des notifications lors des refus. Si les RFCs sont relativement peu verbeuses sur le sujet, on peut néanmoins y trouver les recommandations suivantes :

• RFC 2505 :

1.5. Where to block spam, in SMTP, in RFC822 or in the UA

Our basic assumption is that refuse/accept is handled at the SMTP layer and that an MTA that decides to refuse a message should do so while still in the SMTP dialogue. First, this means that we do not have to store a copy of a message we later decide to refuse and second, our responsibility for that message is low or none - since we have not yet read it in, we leave it to the sender to handle the error.

• RFC 3834 :

2. When (not) to send automatic responses

An automatic responder MUST NOT blindly send a response for every message received. In practice there are always reasons to refuse to respond to some kinds of received messages, e.g., for loop prevention, to avoid responding to "spam" or viruses, to avoid being used as a means to launder or amplify abusive messages, to avoid inappropriately revealing personal information about the recipient (e.g., to avoid an automatic indication that a recipient has not read his mail recently), and to thwart denial-of-service attacks against the responder. The criteria for deciding whether to respond will differ from one responder to another, according to the responder's purpose. In general, care should be taken to avoid sending useless or redundant responses, and to avoid contributing to mail loops or facilitating denial-of-service attacks.

Certains FAIs ou hébergeurs de boites mails voient régulièrement leurs services être utilisés par des spammeurs. Lorsque cela se produit, l'abus n'est généralement détecté qu'après expédition massive de mails non sollicités. Lorsque ces incidents se répètent fréquement, la réputation des serveurs est dégradée et peut même aboutir à un blacklistage (auquel cas, tous les mails, qu'ils soient abusifs ou legitimes, sont rejetés ou bloqués).

Pour éviter cette situation, il peut être tentant de router les mails suspects via des serveurs spécifiques (ou serveurs “poubelles”). Soulagés de ces mails, les serveurs voient leur réputation s'améliorer et rencontrent moins de problèmes pour délivrer les mails. À l'opposé, les serveurs “poubelles” gèrent une concentration plus elevé de mails susceptibles d'être détectés comme étant des spams. Ces serveurs risquent donc d'être blacklistés à tout moment.

Le problème est qu'un mail légitime, mais analysé comme suspect, va être routé par les serveurs “poubelles” puis rejeté par les serveurs du domaine du destinataire (quant bien même l'analyse erronée se fait sur les serveurs de l'expéditeur). Sur ce type de configuration, le signalement du problème doit se faire auprès de son FAI (ou hébergeur de messagerie) et non auprès des services du domaine destinataire.

Malheureusement, il n'y a pas forcément d'information officielle et/ou explicite sur la configuration des serveurs utilisés. Dans certains cas, nous pouvons voir (et signaler) que des domaines utilisent des groupes de serveurs dont le traffic mails est profondément dissymétrique. Mais rien ne nous permet de savoir si cette dissymétrie est bien dûe à un routage de ce type (il peut s'agir de serveurs utilisés par des services différents ou par des utilisateurs différents).

Il y a plusieurs raisons qui peuvent nous pousser à rejeter un mail. Pour chacune de ces raisons nos serveurs renvoient des messages d’erreurs différents qui sont listés ci-dessous, vous trouverez ce message d’erreur dans les fichiers de logs de votre serveur SMTP ou dans un DSN que votre relais vous aura renvoyé.

En aucun cas il n'est conseillé de procéder au déblocage du port SMTP de votre routeur ADSL. Cette manipulation n'est utile que si vous souhaitez héberger votre propre serveur de messagerie (en envoi) derrière votre connexion. Si jamais un périphérique sur votre réseau était compromis, le deblocage du port 25 permettrait à des personnes mal intentionnées de spammer à tout va depuis votre connexion réseau.

Vous avez cette erreur car le mail que vous avez envoyé a été analysé comme étant un spam par notre filtre antispam et il a été refusé lors de la reception.

Il peut être utile de commencer par vérifier que votre mail ne soit pas susceptible d'être confondu avec un spam, que ce soit en utilisant un logiciel antispam ou en vérifiant que votre mail est syntaxiquement correct et que vous n'utilisez pas de mécanismes qui puissent être confondus avec certaines méthodes de spammeurs.

Le cas échéant, nous vous invitons à nous signaler un faux positif en suivant cette procédure.

Explication

Solution

Explication

SMTP (Simple Mail Transfer Protocol) est le protocole qui permet l'échange de mails. Un serveur SMTP est un logiciel permettant le réception et/ou l'envoi de mails.

Un DSN (Delivery Status Notification) est un mail généré par un serveur SMTP lorsqu'il n'arrive pas à envoyer un mail. Il envoie ce mail pour prévenir l'utilisateur que le mail n'a pas pu être délivré. Ce mail contient toutes les informations sur la transaction SMTP.

C'est une erreur qu'un serveur SMTP renvoie à la commande “RCPT TO” lorsque l'adresse mail que vous cherchez à joindre n'existe pas. De nombreux spammeurs générent ce type d'erreur en faisant des spams par dictionnaire.

Si vous êtes administrateur du serveur concerné et que le probleme a été corrigé ou que vous ayez besoin d'informations supplémentaires, vous pouvez envoyer un mail à postmaster@proxad.net, en incluant le message d'erreur du serveur SMTP de Free.fr, l'adresse IP de votre serveur SMTP et l'objet de votre requete.

Si vous êtes simple utilisateur ou que vous n'agissez pas en tant qu'administrateur du ou des serveurs concernés, il ne sert à rien de nous contacter : nous ne ferions que vous confirmer la mise en place du blacklistage. Nous vous conseillons de vous rapprocher du fournisseur du serveur concerné pour lui signaler le probleme.

Attention, cette procédure ne concerne que les mails qui ont été rejetés avec un code commençant par "550 spam detected".

L'objectif est de corriger les filtres antispams pour que ces mails légitimes ne soient plus refusés. Aussi, ce signalement n'a aucun interêt si le problême que vous rencontrez est autre, si votre mail est susceptible d'être confondu avec un spam (mails plus ou moins bien construits) ou s'il s'agit de simples mails d'essais.

Pour corriger ce qui est appelé un faux postif, nous avons besoin de reproduire le problème. Il nous faut donc un mail qui soit aussi semblable que possible de celui qui avait été rejeté. C'est pour cela qu'il vous est demandé de ré-envoyer un mail à l'identique en utilisant les mêmes outils d'expédition et les mêmes serveurs. Si cela est possible (ou ne pose pas de problème), nous vous demandons même d'envoyer le mail aux mêmes destinataires. Si le mail reçu n'est pas détecté comme étant un spam, nous ne pourrons pas faire corriger le problème.

Avant de remonter un faux positif, nous vous demandons de vérifier si votre mail n'est pas susceptible d'être confondu avec un spam. Dans certains cas, le problème peut être assez trivial (un mail vide ne contenant qu'une URL, un mail avec que des destinataires cachés) mais cela peut être un peu plus compliqué avec des mails qui sont générés automatiquement (entêtes incohérentes, encodage qui ne correspond pas à ce qui avait été annoncé dans les entêtes, etc.) voir même très complexe.

Attention, si votre mail est envoyé via les serveurs d'envois de Free (smtp.free.fr), vous ne pourrez mettre que la boite nospam@nospam.proxad.net comme destinataire. Dans ce cas, il est possible que nous vous demandions les destinataires de votre mail (les champs To et CC des entêtes de votre mail original).

Le signalement de faux positif doit se faire :

• en ré-envoyant à nospam@nospam.proxad.net le mail initial (celui qui a été rejeté)
  • avec les mêmes destinataires (sauf si cela n'est pas possible ou est susceptible de provoquer une gêne)
  • avec la boite nospam@nospam.proxad.net en copie cachée
  • avec le même contenu autant que ce peut
  • en utilisant les mêmes logiciels de mailings via les mêmes serveurs
• puis prévenir postmaster@proxad.net de cet envoi en précisant
  • l'expéditeur
  • le sujet
  • le message d'erreur que vous aviez reçu (en mode texte, pas de capture d'écran)

En l'absence de réponse et si le problème perdure, nous vous invitons à relancer après quelques jours (voir un peu plus en période de congés) postmaster@proxad.net (de préférence en répondant à votre propre mail).