said: 550
SC-001 (BAY004-MC4F10) Unfortunately, messages from weren't
sent. Please contact your Internet service provider since part of their
network is on our block list

Traduction : Votre serveur fait n’importe quoi, vous êtes bannis !
Voici un message que j’ai reçu après avoir tenté d’envoyer un mail sur un serveur Microsoft… Et vu que vous êtes ici, peut-être que vous aussi ? C’est fâcheux, car avoir un serveur mail personnel c’est bien, mais si il ne peut plus envoyer de mail à une partie de l’internet, ça ne sert plus à grand chose…
Pas de panique, ça se corrige. Mais retroussez vos manches, car il y a du travail.

1 – Corriger le problème

Le premier point est de découvrir ce qui s’est passé.
Dans mon cas, j’ai découvert qu’un spammeur avait volé le login / mot de passe d’un membre de ma famille et se servait de mon serveur SMTP comme d’un relais de spam. Un petit tour dans les logs de zimbra dans /var/log devrait vous en dire plus.

Une fois le problème identifié, réglez le en coupant l’accès au fautif (changez le mot de passe, etc.).

Ensuite, il faut demander à Microsoft d’être gentil et de vous enlever de leur liste noire. C’est par ici. Si vous avez de la chance, d’ici quelques heures vous pourrez de nouveau envoyer des e-mails. Sinon, vous recevrez un e-mail vous expliquant que non, vous restez bannis. Préparez alors le violon, les mouchoirs, prenez votre plus belle plume et rédigez un joli mail expliquant à quel point vous êtes désolé, ainsi que les actions que vous avez entreprises pour que cela ne se reproduise plus. Pour ma part, ayant été banni deux fois pour des problèmes similaires, c’est ce que j’ai du faire avant de voir mon accès ré-autorisé.

Maintenant, préparez-vous un thé, planifiez un peu de temps sans être dérangé, et suivez ces quelques étapes pour vous assurer de ne plus rencontrer ce genre de problèmes. En effet, c’est malheureux, mais comme vous ne pouvez maitriser le comportement de vos utilisateurs (d’autant plus que leur compte peut se faire usurper), il va falloir prendre des précautions annexes.

2 – Prévention : Activer une adresse catch-all

Une adresse catch-all, c’est une adresse qui accepte tous les mails qui ne devraient pas arriver (par exemple parce que le destinataire n’existe pas). Ainsi, si quelqu’un écrit à « fausseadresse@votredomaine.extension », l’adresse catch-all le recevra.

Pourquoi faire ça ? Pour que les e-mails de type bounce ne soient plus envoyés. Un mail de type bounce, c’est un e-mail de non-délivrance émis par des serveurs de mails. Dans notre cas, cela veut dire que si quelqu’un tape une mauvaise adresse en voulant vous joindre, il ne sera pas prévenu… C’est dommage, mais parfois nécessaire, parce que c’est une méthode parfois utilisé pour envoyer des spams à travers un innocent relais. Je m’explique : on appelle çà les « backscatter bounces ». On se fait passer pour un expéditeur qu’on veut cibler, on vous envoie un mail, et résultat c’est VOTRE serveur qui se retrouve à envoyer un e-mail au faux émetteur qui lui n’a rien demandé. Et comme parfois le contenu ou les PJ sont renvoyés dans les bounces, vous avez alors servi de vilain relais de spamm…

Allez hop :

su - zimbra
zmprov modifyAccount user@domain.com zimbraMailCatchAllAddress @domain.com

 

3 – Prévention : Activer policyd

Un spammeur, pour avoir quelques touches, doit envoyer beaucoup, beaucoup d’e-mail. C’est même souvent à ça qu’on les reconnait. Donc, si vous parvenez à réduire l’activité d’un spammeur qui aurait pris le contrôle d’un compte, vous limitez grandement les dégâts, ce qui vous donne plus de temps pour agir avant d’être banni. Pour ça, on peut utiliser policyd, un démon pour postfix intégré à Zimbra (mais non actif par défaut) qui nous permet d’appliquer des politiques de limitation. En avant :

zmprov ms `zmhostname` +zimbraServiceInstalled cbpolicyd +zimbraServiceEnabled cbpolicyd
zmprov mcf +zimbraMtaRestriction "check_policy_service inet:127.0.0.1:10031"

Ensuite pour activer l’interface web qui rend les choses beaucoup plus simples, il faut lui dire d’utiliser la base de données de Zimbra, pour cela, éditez le fichier /opt/zimbra/cbpolicyd/share/webui/includes/config.php et mettez en commentaire “#” chaque ligne commençant par $DB_DSN. L’objectif est de mettre à la place:

$DB_DSN="sqlite:/opt/zimbra/data/cbpolicyd/db/cbpolicyd.sqlitedb";

Redémarrez Zimbra, et rendez-vous à l’addresse http://votreserveur:7780/webui/index.php (je ne vous fais pas l’affront de vous dire de faire attention avec cette adresse, hein ? Par exemple s’assurer qu’elle ne peut pas être jointe depuis l’extérieur ? Et un fichier .htaccess ? Hein, vous êtes grand, non ?)

Ensuite, comme j’ai la flemme, je recopie un article :

1.     Select Quotas | Configure menu
2.     In the Action options, select Add and enter the details as below :
   Name : Delivery Per User
   Track : Select Sender@domain. This means that policy will be applies to each user on the domain
   Period : The length of time that given in seconds. Ideally is in counts per hour or 3600 seconds
   Link to policy : Select Default
   Verdict : The rules that will be apply if it meets the period, such as defer (hold the messages until next time interval)
   Data : Information that is given if it meets the rule, for example the information is a “Maximum 2 email delivery per minute” or “Maximum 300 emails delivery  per hour”
   Stop processing here : choose Yes, means that rule will not processing another rule
   Comment : can be filled with anything you like
3.     Click Submit
   by default, the newly created rule set in the disabled state. Set it enable by choose PolicyD that you just created, and then on the Action option, select change
4.     Change the parameter Disable=’Yes’ to Disable=’No’ on the Disabled option and click submit
5.     Select the newly created policy again  and then select Limits on the Action option
6.     Select Add, then select the Message Count and fill in with the number of maximum emails  on Counter Limit
7.     Click Back to Limits and choose the rule that you have just created. Select Change In the Action option
8.     Change the parameter ‘Yes’ to ‘No’ on the Disabled option and click submit

Je suppose que 100 e-mails par heure, ça laisse de la marge. A vous de voir selon vos usages.

4 – Surveillance : les logs

Vous l’avez vu en 1 lorsque vous avez cherché le coupable : les logs ont toutes les informations nécessaires pour détecter les mauvais usages. Par exemple :

Oct 30 08:49:20 mail amavis[18001]: (18001-16) FWD from <addresse@yahoo.com> -> <addresse@alice.it>,<addresse@alice.it>,<addresse@gmail.com>,<addresse@hotmail.com>,<addresse@hotmail.it>,<addresse@hotmail.it>,<addresse@libero.it>,<addresse@msn.com>,<addresse@yahoo.com>,<addresse@yahoo.com>,<addresse@yahoo.fr>,BODY=7BIT 250 2.0.0 from MTA(smtp:[127.0.0.1]:10025): 250 2.0.0 Ok: queued as E5D0D1A0164

En gras, à moins que vous ne soyez Yahoo (!), on voit bien que quelqu’un à envoyé un e-mail avec votre serveur en se faisant passer pour quelqu’un d’autre. J’ai fait un petit script python pour détecter ce genre de fraude. Renseigner les paramètres en début de script pour déterminer les adresses légitimes qui vous appartiennent (y compris les adresses spéciales de votre domaine, comme celle recueillant les spams par exemple), ainsi que l’adresse pour recevoir le rapport si quelque chose est détecté, configurez ensuite une tâche cron pour une exécution fréquente (genre toutes les 10 minutes), et enfin soupirez de soulagement. Ce n’est pas parfait bien sûr, car les spammeurs peuvent utiliser vos adresses en tant qu’adresses émettrices. Cependant c’est plutôt rare et cela devrait couvrir de nombreux cas.

Félicitations, vous avez fait quelques pas pour vous prémunir d’un prochain bannissement !