Postfix

Postfix est un serveur de courriel, un Mail Transport Agent (MTA).

Déroulement de la réception d'un couriel

La documentation est difficile à suivre pour comprendre ce qui se passe quand un courrier est reçu, et surtout dans quel ordre.

Apparemment:

Déterminer le type de traitement

• $virtual_alias_maps réécrit des adresses avant toute chose
• La table 'transport' est ensuite utilisée pour déterminer qui va traiter le mail
  • La comparaison se fait par adresse complète, puis par domaine
• S'il n'y a pas de correspondance, on passe aux règles par défaut, en cherchant le domaine notamment dans $mydestination (local), $virtual_mailbox_domains (virtual), $relay_domains (relay), etc. (trivial-rewrite(8)).
• Sinon $default_transport (smtp)

Les types de traitement

La destination est une entrée de master.cf + un nom d'hôte (par défaut la machine locale). Les entrées par défaut incluent principalement local, virtual, relay, smtp. (transport(5))

• local: possède tout un artirail d'actions pour savoir où ranger le mail. D'après postconf(5): The precedence of local(8) delivery features from high to low is: aliases, .forward files, mailbox_transport_maps, mailbox_transport, mailbox_command_maps, mailbox_command, home_mailbox, mail_spool_directory, fallback_transport_maps, fallback_transport and luser_relay.
• virtual: moins complet que local, il range l'e-mail dans $virtual_mailbox_maps mais de manière dissociée des utilisateurs locaux (/etc/password). Cela permet de gérer plusieurs domaines courriel complètement indépendants.
• smtp: pour relayer vers une machine tierce (par exemple au sein d'un réseau privé avec une seule IP publique)

Alias

(Note: ceci est à vérifier, peut-être dû à un problème de configuration plutôt qu'à une règle générale)

Noter que quand un e-mail est réécrit suite à un alias, le traitement de l'e-mail en recommence pas depuis le début. Autrement dit, il n'est plus possible d'appliquer les règles en amont sur l'e-mail réécrit. En particulier, les e-mails en partie droite de /etc/aliases ne seront pas soumis aux règles de $virtual_alias_maps. Apparemment cela permettrait d'éviter des boucles.

Ça a l'air d'être confirmé dans la documentation de Sympa.

Filtrage des courriels

• D'abord des tests sur l'e-mail durant les différentes étapes de chaque connexion à Postfix
  • smtpd_helo_restrictions (HELO/EHLO)
  • smtpd_sender_restrictions (MAIL FROM)
  • smtpd_recipient_restrictions (RCPT TO)
  • (d'autres?)
• Puis, dans tous les cas, le filtrage de contenu:
  • content_filter

Dans les restrictions, on peut effectuer certains tests tardivement, par exemple un test sur le HELO peut s'effectuer dans la partie "recipient".

Dans les restrictions, il est possible d'ajouter différents tests pré-cablés:

• permit_sasl_authenticated
• reject_invalid_helo_hostname

ou de passer la main à des classes, déclarées avec smtpd_restriction_classes, par exemple:

smtpd_restriction_classes = greylisting, rbl
rbl =
 reject_rbl_client bl.spamcop.net,
 reject_rbl_client zen.spamhaus.org

ou d'effectuer des tests suivant une table, qui elles même feront références sur d'autres actions:

• check_client_access: tests sur IP ou nom d'hôte
• check_sender_access: tests sur l'expéditeur (l'enveloppe, pas le From:)
• check_recipient_access: le destinataire (idem)

Les tables peuvent également utiliser des actions spéciales (cf. access(5)):

• ACCEPT
• REJECT
• DUNNO: fait comme si l'entrée n'avait pas été trouvée
• DISCARD: accepte le courriel mais le supprime tout de suite après
• FILTER qqchose: change la valeur de content_filter pour ce client

Quand on passe dans une classe, et que le message n'a pas eu d'action définitive (acceptation ou rejet), le contrôle revient à la ligne suivant la référence à cette classe (comme un appel de fonction en programmation).

Documentation

• Postfix Configuration Parameters
• Postfix Architecture Overview: trop axé sur l'architecture interne de Postfix, mais une bonne lecture après avoir compris cette page wiki