Sur une infra composée de plusieurs machines physiques ou virtuelles (VM, LXC, etc.), on utilise ssmtp (voir http://shaarli.guiguishow.info/?Qn9K_Q ) pour que ces machines envoient leurs emails (genre ceux des démons comme cron qui envoient les erreurs à postmaster@ ou root@ ) à un serveur de mail central, le serveur de mail désigné pour toute l'infra. Ça permet que les serveurs de mails de l'infra soient clairement identifiés (utile pour du SPF / DKIM, le debug et la cohérence) sans qu'un MTA complet (postfix, exim, sendmail, etc.) soit installé sur chaque machine (relou à configurer, etc.).

Et, sur le serveur de mails central, on utilise anvil, module de postfix, pour limiter le nombre de mails qu'une adresse IP pourra envoyer via notre serveur sur une quantité de temps définie. Cela permet que, si une machine ou même une application web qui sait émettre des emails, se fait trouer, votre infra n'inonde pas les Internets de spam sinon ça va plutôt mal se passer pour la réputation de vos adresses IP.

Bout de config inspiré de celui pointé par ce shaarli (ici : 100 mails provenant de votre infra ou non / IP / jour ) :

smtpd_client_message_rate_limit = 100
anvil_rate_time_unit = 1d
smtpd_client_event_limit_exceptions = 

Par défaut, « smtpd_client_event_limit_exceptions » a pour valeur « $mynetworks », ce qui permet aux machines définies (par défaut la machine elle-même) de contourner la restriction. Je ne pense pas que ça soit la bonne approche, surtout s'il y a une application web ou autre sur la même machine que le serveur mail.

« smtpd_client_event_limit_exceptions » permet aussi d'exclure certaines adresses, comme celle du monitoring qui peut être légitime a beaucoup hurler lors d'une panne sérieuse.