# uname -a - Mot-clé - exim

Diminuer le taux de rejet des mails sortants pour un fournisseur de boîtes mail

Mathieu — Tue, 09 Feb 2016 21:06:00 +0100

En théorie, tout le monde peut s’improviser fournisseur d’emails, il suffit d’une machine avec les ports ouverts sur Internet et de quelques connaissances pour configurer le serveur mail (Postfix, Exim…)

En pratique, les fournisseurs de mails subissent la « concurrence déloyale » de leur camarades, car envoyer un mail c’est bien, faire en sorte qu’il soit reçu c’est mieux. Les « concurrents » ce sont les fournisseurs de service comme Hotmail, Gmail, Yahoo, et bien d’autres. Afin de lutter contre le SPAM, ces sociétés sont de plus en plus strictes sur la source des mails qui sont reçus par leurs services.

Une des conséquences c’est que les petits opérateurs, comme une start-up qui fournit de l’hébergement, un FAI associatif, ou même un particulier qui veut se réapproprier Internet, se font bloquer assez rapidement avec peu de solutions de recours, le support faisant souvent la sourde oreille.

Dans cet article, je vais donc explorer quelques pistes pour vous permettre d’abord d’éviter de vous retrouver bloqués, et ensuite contourner le blocage le cas échéant.

Ce billet est le produit de mes expériences avec l'hébergeur wellhosted.

Réputation (et monitoring)

Déjà, si vous avez une adresse IP dynamique, oubliez l’envoi de mails. Il est très difficile avec une IP dynamique d’assurer à la fois une réception correcte (même avec un MX pointant sur un DynDNS), et un envoi qui réussisse à tous les coups. D’ailleurs, la plupart des opérateurs proposant des IPs dynamiques bloquent le port 25, rendant l’envoi des mails « entre serveurs » impossible.

Ensuite, la seconde bonne raison pour avoir une IP fixe, c’est que les contrôlent antispam reposent en grande partie sur la réputation des IPs qui leur envoient des mails. Ce mécanisme s’appelle le RBL pour Realtime Block List. Les serveurs s’abonnent à des listes d'adresses IP connues pour émettre du SPAM, et refusent de recevoir les mails depuis ces IPs. Pas de chance si vous avez hérité d’une IP « qui pue », il vous faudra patiemment demander votre retrait de la liste de blocage au cas par cas.

Il existe des outils pour tester votre IP sur un grand nombre de RBL : mxtoolbox.com/blacklists.aspx

Vous pouvez également mettre en place une surveillance automatique de votre réputation sur plusieurs blocklists, soit avec un simple plugin Nagios, soit avec un outil comme RBLMon.

A noter que certaines listes ne permettent pas de faire « retirer » votre IP de la liste. Pas d’inquiétude pour ces listes, personne ne les utilise. Il existe par contre des fournisseurs de service qui ne publient pas leurs listes, et qui ont un processus contraignant pour se faire débloquer (Microsoft par exemple).

Une fois que votre IP est fixe et qu'elle est propre, l’étape suivante c’est conserver la réputation de votre IP et être irréprochable sur les mails que vous envoyez, mail nous verrons cela dans la suite.

IPv6

Même si ce n’est pas indispensable, IPv6 est le futur d'Internet, et de nombreux serveurs mails parlent IPv6. En utilisant IPv6, vous aurez aussi l’avantage que beaucoup de RBL ne sont pas prêtes pour IPv6, et donc votre IP ne sera certainement pas bloquée sur ces listes.

Revers de la médaille : oubliez l’utilisation d’une IPv6 exclusive, certains fournisseurs de mail utilisent encore exclusivement IPv4, il vous faudra donc une configuration réseau supportant les deux adressages pour être certain de pouvoir livrer vos mails.

Reverse, PTR, et Hostname

Le « Reverse », parfois nommé « PTR », est une résolution DNS inverse. De la même façon qu'une résolution DNS permet de passer d'un nom de domaine à une adresse IP, le DNS inverse permet de passer d'une adresse IP à un nom de domaine. Ce mécanisme existe aussi bien pour IPv4 que pour IPv6.

Si votre fournisseur de service (la personne chez qui vous louez les IPs ou les serveurs) ne vous permet pas de changer le Reverse, changez de prestataire immédiatement ! L'envoi d'un mail à partir d'une adresse IP sans Reverse est souvent rédhibitoire pour le serveur mail de destination (pas de reverse, pas de livraison).

De plus, votre Reverse doit être consistant :

L'adresse IP doit résoudre vers un domaine, et ce même domaine doit résoudre vers l'adresse IP.
Le serveur mail doit également fournir son nom de domaine principal dans le processus de négociation, et ce nom doit résoudre correctement vers son IP. Réglez donc les /etc/hostname ; /etc/mailname et myhostname (pour Postfix) correctement.

Une inconsistance à un quelconque niveau est pire qu'une absence de reverse : le serveur de destination considérera qu'il y a peut-être usurpation de l'IP.

Encore une fois, n'oubliez pas de régler aussi le reverse IPv6 si vous utilisez IPv6 sur votre serveur.

Postmaster, Hostmaster, et RFC

Certains serveurs mails sont un peu soupe au lait. Par exemple, il peut arriver que votre réputation descende en flèche juste parce que le propriétaire du serveur n’a pas de moyen automatisé de vous contacter.

J’explique : dans les RFC (Request For Comment, la base des normes et protocoles sur Internet), il est prévu qu’un serveur mail émettant du courrier possède des adresses particulières, à savoir postmaster@ledomaine.com et hostmaster@ledomaine.com permettant de recevoir les mails envoyés automatiquement par ses pairs.

postmaster recevra principalement les plaintes pour SPAM, notification de traffic inhabituel sur les mails, et autres requêtes relatives aux mails
hostmaster recevra les mails relatifs à la gestion du nom de domaine lui-même (demandes de transfert, contact légal du propriétaire - même si on préfère souvent écrire aux contacts du whois), ou parfois pour la réservation d’un certificat SSL (vérification de la propriété du nom de domaine avant délivrance automatique du certificat).

L’absence d’une adresse postmaster@ valide sur votre serveur vous fait donc paraître pour le serveur mail de destination comme un spammeur qui n’a même pas pris la peine d’implémenter correctement le protocole mail.

A noter qu’un alias de postmaster@ vers une adresse de votre choix fonctionne aussi, même si cette adresse est un trou noir. Mais vous ne devriez pas ignorer les notifications automatiques de blocage et de plaintes envoyées à postmaster…

De la même façon, préférez un logiciel de serveur mail respectueux des standards (Postfix, Exim) au tout-dernier-serveur-mail-a-la-mode, dont les réponses ne sont peut-être pas entièrement conformes aux RFC.

Limites

Là on touche au grand dilemme du fournisseur de mails en serveur mutualisé : offrir plus de possibilités aux utilisateurs, ou se protéger contre les usages abusifs ?

Concrètement, imaginons qu’un de vos utilisateurs décide d’envoyer de la publicité aux 500 adresses mail de sa liste de contacts. Les serveurs recevant un tel volume de messages d’un seul coup ne vont peut-être pas apprécier ce trafic non sollicité et encombrant (de la pub ? du SPAM ? Paf, bloqué).

Pire : imaginez qu’un de vos utilisateurs se fasse pirater sa boîte mail, et devienne un émetteur de SPAM ou de virus à partir de votre serveur mail ? Vous pensez que les serveurs de destinations seront compréhensifs s’ils reçoivent des centaines de mails par seconde provenant de votre serveur mail ? Ils ne chercheront pas à comprendre : paf, bloqué.

La solution dans un premier temps c’est de limiter le nombre de mails envoyés par votre serveur, par adresse et par jour. Chaque utilisateur ne devrait par exemple envoyer que 300 mails par jour. Au-delà, le compte sera bloqué en attendant que l’on détermine si c’est une utilisation légitime ou non. La limite est bien entendu à calibrer selon les utilisateurs et les services que vous voulez offrir.

Il existe plusieurs solutions pour implémenter ce comportement, voici la mienne : github.com/mpellegrin/ratelimit-policyd

Diminuer la vitesse d’envoi

Ça peut paraître un comble au moment où l’on veut recevoir les informations le plus vite possible, et pourtant c’est souvent nécessaire pour l’envoi de mails. Afin d’éviter d’envoyer trop vite un grand volume de mail d’un coup, il peut être nécessaire de mettre en place une limite de mails sortants par seconde et par domaine de destination. Ainsi, le serveur mail de destination ne sera pas inondé sous le poids des mails à traiter, et sera plus coopératif pour les recevoir (en résumé : il ne vous bloquera pas pour usage abusif de sa bande passante).

La mitigation du taux d’envoi peut être faite au moyen de simples paramètres pour le serveur mail steam.io/2013/04/01/postfix-rate-limiting/

DKIM et SPF

Avoir un enregistrement SPF valide pour le domaine avec lequel vous envoyez vos mails est pratiquement obligatoire : non seulement cela vous permettra de confirmer que le serveur qui envoie vos mails y est bien autorisé, mais cela vous protégera (un peu) contre les usurpations d'adresses mail. Un exemple de SPF serait :

v=spf1 +a +mx -all

Si vous voulez un effet positif maximal, préférez un réglage strict ("-all") au réglage de debug ("?all"), quitte à élargir votre jeu de règles en insérant toutes vos IPs. Par contre, ne mettez pas un TTL trop haut sur les enregistrements SPF, on ne sait jamais.

Attention également, pour configurer votre domaine, le champ de type "SPF" est obsolète, utilisez un champ de type TXT pour vos enregistrements SPF.

En complément au mécanisme SPF, parce que le SPF n'est pas toujours suffisant pour assurer au serveur de destination que le mail est légitime, vous pouvez mettre en place le DKIM pour tous vos mails sortants. La configuration est plus complexe, mais elle vaut largement le coup pour vous faire sortir de l'ornière d'une réputation trop faible de votre adresse IP dans les premiers mois.

Le principe du DKIM c'est d'ajouter une signature aux mails, cette signature étant calculée à partir d'une clef privée. La clef publique est quant à elle publiée dans un enregistrement TXT dans le nom de domaine, permettant au serveur recevant le mail de vérifier la validité de la signature, et donc la légitimité du message envoyé à partir du nom de domaine.

Smarthosts

Si finalement tout ce dont j'ai parlé plus haut n'a pas fonctionné, et que vous vous êtes fait bloquer sur le réseau d'un des grands fournisseurs de boîtes mail (Google, Microsoft, yahoo...), voici votre dernier recours.

Outre changer d'adresse IP, ce qui pose souvent d'autres problèmes, votre solution c'est d'utiliser un Smarthost. Le Smarthost, c'est tout simplement un serveur mail qui transfère des mails. C'est ce que l'on appelle aussi un relay mail, qui va renvoyer tous vos mails à la place de votre serveur bloqué.

Dans l'idéal vous devriez avoir plusieurs smarthosts, pour pouvoir répartir la charge de traitement, et les échanger lorsque l'adresse IP de l'un d'eux se fait bloquer. Ainsi vous ne touchez pas à vos MX, et vous avez un réseau permettant de faire sortir des mails indépendemment de votre réseau de réception.

Le routage vers le Smarthost se règle très simplement dans Postfix, en utilisant la directive transport_maps de Postfix et en configurant un second serveur mail (le smarthost) en mode Relay.

Attention cependant au moment de créer votre smarthost à ne pas créer de configuration en "Open Relay", qui permettrait à n'importe qui d'envoyer des mails à travers le smarthost, la sentence sera immédiate lorsque des spammeurs s'en apercevront. Réglez bien votre mynetwork, et sender_restrictions (par exemple avec Postfix).

Pour aller plus loin

Voici une liste d'outils assez pratique lorsque l'on configure ou que l'on cherche la cause d'un problème de délivrance sur un serveur mail :

Mail Tester (indispensable pour vérifier votre configuration)
MXToolbox (le couteau suisse des tests sur les serveurs mails)
Quelques conseils de Google

Quelques liens pour (essayer de) se faire retirer de la Blocklist :

Pour se faire dé-bannir par Microsoft (sans garanties...)
Pour se faire dé-bannir par Google (sans garanties)
Pour se faire débannir par Yahoo (sans garanties)
Pour se faire débannir par AOL (sans garanties)

Les programmes de monitoring de réputation :

Un serveur au régime : faites tourner un serveur complet dans un mouchoir de poche

Mathieu — Mon, 25 Nov 2013 07:15:00 +0100

Introduction

Ce n’est pas la période pour les régimes et pourtant aujourd’hui, dans un billet volontairement cryptique aux non-initiés, je vais vous dévoiler les quelques secrets qui permettent à des nerds invétérés de donner vie à des machines ridiculement pauvres en RAM. Pour la beauté du geste, mais pas que.

Je me souviens que l’on s’est souvent moqué de moi quand je disais qu’avec 512 mégas de RAM on pouvait faire tourner un serveur complet mail+ftp+web+sql. En remplaçant quelques programmes, vous pouvez parfaitement faire tourner votre application web standalone, un noeud de CDN performant, un miroir FTP, ou un relais mail.

Cet article va simplement vous présenter des alternatives, et terminer avec quelques astuces plus générales. Le but est de remplacer notre célèbre LAMP par des solutions moins gourmandes en mémoire.

Remplacer Apache

Pour remplacer Apache, nous avons le choix entre Nginx et Lighttpd (Lighty).

Lighttpd est le serveur le plus léger au monde. Sa structure est très simple, et l’impact d’une connexion en mémoire est très faible.

Nginx est un serveur qui consomme un peu plus au démarrage, mais qui utilise une gestion intelligente de ses connexions ouvertes pour optimiser son impact mémoire.

Inconvénients : oubliez les .htaccess, préparez-vous à faire un peu de configuration pour remplacer votre “a2enmod php5”, et changez vos habitudes pour redémarrer les services.

Remplacer MySQL

Ce n’est pas facile de remplacer MySQL, tellement le nombre de programme qui en dépendent est conséquent. Cependant, si c’est possible, n’hésitez pas une seconde, voici les deux alternatives “lowcost” possibles :

SQLite : une base SQLite est simplement un fichier qui est chargé en mémoire au moment où l’on veut lire dedans. Pas de démon résident, pas d’impact lorsque la base est inactive. Par contre, préparez vous à attendre un peu si votre base est conséquente : lire des données en n’utilisant que le cache disque, ça peut prendre du temps.

PostgreSQL : PostgreSQL est un peu le nouveau MySQL, mais en mieux. de faible impact mémoire au démarrage, doté de plus de fonctionnalités que MySQL et proposant de meilleures performances, il reste encore marginal mais a tout pour concurrencer les équivalents propriétaires comme Oracle. On peut l’utiliser dans un environnement limité, en configurant correctement les limites dans sa configuration.

Remplacer ProFTPd

Si vous proposez un hébergement, vous proposerez certainement un serveur FTP.

Si les utilisateurs du serveur sont des utilisateurs “de confiance” (ie : que vous connaissez), vous pouvez leur laisser utiliser le serveur SFTP fourni par le serveur SSH (à activer dans la configuration). De très faible impact mémoire, pour une meilleure sécurité et moins de configuration, le protocole SFTP est supporté par la majorité des clients FTP. C’est LA solution des flemmards pour mettre en place un serveur FTP.

Sinon, vous pouvez vous rabattre sur un VSFTPd, qui en plus de vous combler au niveau impact mémoire, vous comblera au niveau rapidité. Il gère aussi le FTPS.

Remplacer Postfix

Si vous n’utilisez pas la réception des mails et que vous ne faites que de l’envoi (avec ou sans smarthost), Exim vous comblera au moins autant que Postfix, vous proposant même sous Debian une interface de configuration “pour les nuls” : dpkg-reconfigure exim4-config.

Éviter la catastrophe

En cas de gonflement inattendu de la mémoire, et lorsque celle-ci commence à manquer, le système d’exploitation commence à sacrifier des programmes pour libérer de la RAM. C’est dommage, on aimerait éviter d’en arriver à de telles extrémités sur un serveur de production.

La solution est assez simple, bien qu’imparfaite : il suffit de rajouter de la SWAP. La SWAP est un fichier d’échange placé sur le disque dur, lorsque il n’y a plus de mémoire en RAM, une partie de la RAM est déchargée (ie copiée) sur la SWAP, pour laisser de la place aux programmes “actifs”. Bien entendu, cette mémoire déchargée devra être rechargée dès lors qu’un programme a besoin d’un bloc mémoire qui a été placé en SWAP, ralentissant le traitement à la vitesse des temps d’accès disque (pas cool).

Faire dormir tout le monde

Ce qui est pénible avec les serveurs, c’est la quantité de RAM qui est là, utilisée en permanence, pour finalement un seul pic d’utilisation. Si on pouvait récupérer la RAM des programmes qui n’interagissent pas avec l’extérieur, et ne les lancer que quand on en a besoin ? Inetd est fait pour ça !

Inetd c’est un “super démon” qui va écouter sur les ports demandés à la place des programmes, et qui va lancer les programmes pour traiter l’événement, dès lors qu’une connexion est ouverte sur un de ses ports d’écoute. On peut donc imaginer avoir un Lighttpd non lancé qui se fait réveiller lorsque Inetd reçoit une connexion sur le port 80. Lighttpd traite alors la requête et s’arrête immédiatement après, laissant la place pour d’autres programmes.

L’inconvénient ici vient des temps de traitement forcément plus longs qu’avec des démons résidents (démarrer le programme prend du temps).

Conclusion

Voilà, c’est à peu près tout, j’espère qu’avec ces petits changements dans votre configuration, vous aurez quelques pistes pour alléger votre serveur, si jamais l’expérience vous tente.