Nous venons d’être blacklisté par les serveurs de mail de free.fr :
L’IP xx.xx.xx.xx est blacklistée pour une duré de 77841s (too many errors (unexisting recipients, broken connections), rejecting mail)
or en consultant la log de notre serveur bluemind, nous constatons que des adresses farfelues @free.fr (certainement inexistantes) nous ont envoyés de nombreux mails sur des adresses inexistantes @notreDomaineBlueMind.fr et aussi sur de bonnes adresses mais avec des pièces jointes aux extensions bloquées par notre serveur (ou contenant des virus et donc bloqué également).
A priori le blocage sur les serveurs de messagerie de free.fr est du à nos retours qui ont été envoyé vers les adresses de l’expéditeur @free.fr et que vous avez supposé être du SPAM vers des adresses inexistantes (451 too many errors from your ip et 554 too many errors detected from your IP (xx.xx.xx.xx), please visit http://postmaster.free.fr/)).
Comment sortir de cette impasse ?
Si quelqu’un se trompe d’adresse email à destination de notre domaine mail ou envoie des documents dont les extensions sont bloquées, il est important de le prévenir. Mais comment faire pour ne pas prévenir quand c’est une adresse bidon ou utilisée par un spammeur ?
Si quelqu’un a une piste, je suis preneur.
Merci d’avance.
Normalement, les mails destinés à des adresses inexistantes de votre domaine devraient être rejetés immédiatement, sans même qu’ils soient pris en charge par votre serveur.
Avez-vous une passerelle SMTP située avant le serveur BlueMind ?
Pour votre politique de bloquage sur les pièces jointes… C’est à vous de voir si vous souhaitez prévenir ou pas l’expéditeur, cependant il ne faudrait jamais répondre à un mail qui est détecté comme du SPAM.
Pour le reste, votre serveur est simplement bloqué temporairement par le SMTP de free. Il n’y a rien à faire de particulier, sauf à corriger votre politique de réponse afin de générer moins de mail de ce type.
Il est possible de définir des règles dans postfix afin de limiter le nombre de mails envoyés dans un laps de temps à un serveur, mais ce n’est pas censé être utilisé, sauf dans des cas très précis, ou comme paliatif temporaire.
Merci pour votre réponse. Nous n’avons pas de passerelle SMTP avant le serveur BlueMind.
Je suis d’accord qu’il ne faut pas répondre à un mail détecté comme du SPAM. Je me demande si la détection a bien fonctionné dans ce cas.
Nous avons mis en place un “ralentissement” des envois vers free.fr, comme vous le suggérez. En espérant que cela évitera que ce problème se renouvelle à nouveau.
Sans passerelle il est étonnant qu’un mail destiné a une adresse inconnue de votre domaine ait été pris en charge.
Par défaut, BlueMind rejette les mails dont les destinataires du domaine local sont inconnus.
Ce lignes indiquent bien que ces mails n’ont pas été pris en charge (NOQUEUE).
La machine qui tentait d’envoyer ce mail (IP: 93.64.241.181) a reçu cette erreur lors de la commande SMTP RCTP TO. Votre serveur n’a donc pas généré de mail vers l’expéditeur pour ces cas car il a rejeté le mail avant même de l’avoir pris en charge - c’est éventuellement 93.64.241.181 qui l’a fait.
Effectivement, mais il faudrait voir d’où proviennent ces mails.
Par exemple le mail d’ID 240E7F81E67 a été reçu depuis quelle IP ? Si c’est localhost, qui a émis ce mail, votre anti-spam/anti-virus ? Si oui, ce mail a été émis suite au traitement de quel mail, qui provenait d’où à son tour ?
Ce n’est à priori pas normal que vous ayiez accepté de traiter des mails destinés à des adresses inexistantes.
Je n’ai malheureusement plus les fichiers mail.log pour creuser le mail d’ID 240E7F81E67. Mais ce message a lui été envoyé à un destinataire existant (cigacgueb@artifrance.fr).
Je pense que c’est amavis qui bloque certaines extensions et rejette alors le mail en répondant à l’expéditeur.
Je vais voir pour ne plus prévenir en cas de blocage d’un mail sur pièce jointe avec extension non autorisée, ce qui évitera pas mal de réponses vers des adresses utilisées pour envoyer des virus.
Dans ce cas, le mail d’origine est légitime, il faut donc voir ce qui est faisable/envisageable au niveau de la politique de notification d’Amavis effectivement.
Pour ceux que cela pourrait éventuellement intéresser, pour éviter de notifier en cas de PJ dont le type est banni, dans la config amavis, remplacement de la directive “$final_banned_destiny = D_BOUNCE;” par celle-ci pour ne plus notifier : "$final_banned_destiny = D_DISCARD; ".