Bienvenue sur postmaster.free.fr

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.

Mon IP est elle bloquée ?

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



Comment débloquer mon IP ?

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.

Problème d'envoi vers Free.fr ?

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é :

550 spam detected

Explication

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.

Solution

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.

x50 Too many spams from your IP

Explication

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.

Solution

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.

550 Too many errors from your IP

Explication

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.

Solution
  • 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.

421 Too many errors from your IP

Explication

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

Solution
  • 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.

F.A.Q

Utilisez vous des RBL publiques ?

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

Combien de temps dure le blocage ?

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

Qu'avez vous contre les mails non sollicités ?

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

Pourquoi avez vous mis en place une blackliste ?

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

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

Pourquoi ne voulez-vous pas de mes notifications automatiques ?

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.

Effets de bords liés au routage selectifs des mails

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

Problème d'envoi depuis le réseau de Free ?

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.

550 spam detected

Explication

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.

Solution

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.

421 too many connections

Explication

Cette erreur peut arriver dans deux situations :

  • plusieurs connexions simultannées depuis votre connexion réseau
  • de trop nombreuses connexions ont été ouvertes depuis votre connexion réseau

Solution

S'il s'agit d'un problème de connexions simultannées, il ne devrait se produire qu'exceptionnellement.

Dans les autres cas, il s'agit d'un blocage temporaire (quelques heures) dont l'objectif est d'éviter que les serveurs ne puissent être engorgés par quelques utilisateurs (ou plutôt par quelques ordinateurs compromis utilisés pour envoyer des mails non sollicités à tout va).

Il est toutefois possible que ce blocage soit provoqué par une utilisation intensive des serveurs SMTP (mailing par exemple) mais les quotas mis en place couvrent largement une utilisation personnelle des serveurs.

S'il s'agit d'un problème récurrent, il va être necessaire de trouver qui sur votre réseau est susceptible d'envoyer de manière récurrente voir continu des mails. Les points suivants peuvent être vérifiés :

  • les dossiers d'expédition des différents clients de messagerie (certains clients mails ne prennent pas en compte les codes retours des serveurs SMTP et peuvent tenter d'envoyer encore et toujours des mails qui sont rejetés par les serveurs SMTP)
  • la bonne santé de votre parc informatique (certains troyens ou virus utilisent les relais SMTP pour envoyer des mails non sollicités)
  • un bon niveau de sécurité de votre réseau informatique (nottament sur les bornes wifi qui peuvent être utilisés à votre insu par des voisins qui peuvent, eux aussi, être infectés)

421 too many recipients/421 too many mails

Explication

Cette erreur peut arriver si nos serveurs ont comptabilisé un grand nombre de destinataires/mails en provenance de votre connexion. À moins que vous ne soyez en train de faire un usage intensif des serveurs SMTP, nous vous invitons à consulter la rubrique Solution ci-dessus

Glossaire

Qu'est qu'un serveur SMTP ?

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.

Qu'est qu'un DSN ?

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.

Qu'est qu'une erreur user unknown ?

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.

Contact

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.

Signalement de faux positifs

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.

Il est délicat de remonter les faux positifs car, si leur détection se repose en grande partie sur le contenu du mail, les filtres antispams peuvent être assez sensibles à certaines erreurs ou incohérences (typiquement des entêtes mal construites) voir même au comportement du ou des relais de messagerie par lesquels les mails transitent.

Aussi, un signalement de faux positif doit se faire en envoyant à nospam@proxad.net le mail rejeté :

  • à l'identique (pas de mail de test, pas de sujet modifié, pas d'attachement, de forward ou autre manipulation)
  • en utilisant (autant que possible) les mêmes logiciels de mailings via les mêmes serveurs
Ceci pour que nous puissions recevoir un mail aussi proche que possible du mail qui avait été initialement rejeté.

Une fois ce mail envoyé, il vous faut 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 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).