Monitorer son infra, ce n'est pas juste vérifier qu'une machine / un service est accessible. C'est aussi vérifier automatiquement que la conf' n'est pas trouée par des modifications ultérieures. Exemples : il faut vérifier que le smptd n'est pas un relais ouvert, que le récursif-cache DNS n'est pas ouvert, même chose pour snmpd, ntpd et d'autres...
Suite au passage à Jessie, Picomon (ordonnanceur de supervision ultra léger et KISS, voir
http://shaarli.guiguishow.info/?QdWF1g) nous signale que notre smtpd ne répond plus comme avant au test de relais ouvert. En effet, postfix répond 454 (erreur temporaire, revient livrer ton mail plus tard) au lieu de l'habituel 554 (refus définitif, ce mail ne sera jamais accepté, arrête d'essayer).
Lisons les release notes :
« With Postfix versions before 2.10, the mail relay policy and spam
blocking policy were combined under smtpd_recipient_restrictions,
resulting in error-prone configuration.
As of Postfix 2.10, the mail relay policy is preferably implemented
with smtpd_relay_restrictions, so that a permissive spam blocking
policy under smtpd_recipient_restrictions will not unexpectedly
result in a permissive mail relay policy.
As of Postfix 2.10.0 the smtpd_relay_restrictions parameter built-in
default settings are:
smtpd_relay_restrictions =
permit_mynetworks
permit_sasl_authenticated
defer_unauth_destination
If your site has a complex mail relay policy configured under
smtpd_recipient_restrictions, this safety net may defer mail that
Postfix should accept. »
defer_unauth_destination = 454 ; reject_unauth_destination = 554.
Ce postfix n'est pas un relais légitime. De plus, ce comportement semble être temporaire afin de faciliter les migrations et je pense que les dev postfix passeront à reject_unauth_destination dans quelques temps. Donc autant le faire dès aujourd'hui.
Pour ce faire, on ajoute ce qui suit au main.cf :
« smtpd_relay_restrictions =
permit_mynetworks,
permit_sasl_authenticated,
reject_unauth_destination »
Et on reload postfix.