frangipane/ Email

franGiPane - email

  1. Sources de documentation
  2. Amavis
  3. Adresses email spéciales (gérées par Debian)
  4. Coexistence listes / boîtes-aux-mails / alias
  5. Mode maintenance
    1. Postfix / briques de base
    2. Postfix / nos adresses
    3. Aliases
    4. courier / webmail / relais SMTP
    5. Listes
  6. Limitations du modèle

Pages liées :

Sources de documentation

Amavis

Il sait aller taper dans des fichiers plats et/ou SQL pour savoir quels sont les domaines gérés en local.

Adresses email spéciales (gérées par Debian)

Exemple : abuse, postmaster, root, etc.

Elles ne peuvent être entrées dans franGiPane, et :

  • pour boum.org : on les gère à la main dans /etc/aliases et dans hash:/etc/postfix/ ;
  • pour les autres domains, elles sont générées automatiquement dans la vue mail.aliases_on, pour chaque domaine hébergé.

Coexistence listes / boîtes-aux-mails / alias

TODO On ne doit pas pouvoir entrer dans franGiPane une bam/alias telle que username{,-admin,-bounces...} corresponde au nom d'une liste existante.

Mode maintenance

Nous devons/voulons absolument pouvoir aisément désactiver le mail pour un domaine, d'un coup, parce qu'on en a besoin lors d'une migration de domaine, par exemple ; idéalement, il doit suffire de mettre domain.mail_status='maintenance' pour :

  • passer tout un domaine en mode error:try again later, côté Postfix
  • désactiver les logins POP/IMAP/webmail
  • désactiver le relais SMTP

Postfix / briques de base

Sources d'inspiration :

Il s'agit de jouer avec la variable transport_maps, qui prend le pas sur le comportement de routage par défaut. Postfix interroge les sources listées dans cette variable en leur demandant quel transport utiliser pour une adresse donnée.

En l'occurrence, dans /etc/postfix/main.cf, on met :

 transport_maps =  pgsql:/etc/postfix/transport.cf, hash:/etc/postfix/transport

Et dans /etc/postfix/transport.cf :

query = SELECT result FROM transport('%d')

Ainsi, grâce à ce subtil '%d', lorsqu'il s'apprête à recevoir un mail destiné à ADRESSE@DOMAINE.TLD, la première requête effectuée par Postfix demande à franGiPane quel transport utiliser pour DOMAINE.TLD.

Et ça tombe bien, tiens, la pseudo-table SQL mail.transport (Cf la doc de PostgreSQL, 7.2.1.4. Table Functions) renvoie :

  • error:Try again later, lorsque DOMAINE.TLD est en maintenance ;
  • rien du tout, sinon, afin que Postfix, dans l'ordre, en s'arrêtant dès qu'il obtient une réponse :
    • demande à la seconde source (hash:/etc/postfix/transport) ce qu'il doit faire pour ADRESSE@DOMAINE.TLD ;
    • demande à cette même seconde source ce qu'il doit faire pour DOMAINE.TLD ;
    • se rabatte sur son comportement de routage par défaut : utiliser le transport local pour les adresses des users shell, et le transport maildrop pour les adresses virtuelles.

TODO Les méthodes qui font entrer/sortir un domaine dans le / de maintenance ne doivent pas oublier d'activer / désactiver soft_bounce dans main.cf...

Postfix / nos adresses

Vérifions tout de même, au passage, que cette solution fonctionne aussi pour nos adresses d'users shell @boum.org.

Il y a d'une part celles qui sont locales (i.e. tout le monde sauf zorglub & intrigeri) n'apparaîssent pas dans franGiPane. Ce qui se passe :

  • lorsque boum.org est 'on' : aucune des deux transport_maps ne donnera de réponse, et le comportement par défaut (transport local) sera utilisé ;
  • lorsque boum.org est en maintenance : la map pgsql renverra error:try again later.

Parfait.

Et il y a d'autre part celles qui sont virtuelles (i.e. zorglub & intrigeri), par contre, doivent apparaître dans franGiPane, ne serait-ce que pour qu'on puisse les relever en POP/IMAP. Or, dans le monde pré-fGP, notre astuce pour permettre leur fonctionnement était de leur donner explicitement 'maildrop' pour transport. Il nous faut donc garder la source hash:/etc/postfix/transport actuelle, qui contient :

 intrigeri@boum.org  maildrop
 zorglub@boum.org    maildrop

Ainsi :

  • lorsque boum.org est 'on' : la première source (pgsql) de transport_maps ne donnera pas de réponse, et la seconde dira maildrop ;
  • lorsque boum.org est en maintenance : la source pgsql répondra error:try again later.

Parfait aussi.

C'est donc censé marcher.

Aliases

Ce mode "maintenance" basé sur transport_maps ne fonctionne pas à l'identique pour les aliases, vu que qmgr / trivial-rewrite n'interrogent pas ces tables pour les aliases.

Le seul moyen aisé de faire rentrer les aliases dans le moule est de cacher leur existence lorsque leur domaine est en maintenance : dans ce cas, ils n'apparaîssent pas dans la vue mail.aliases_on, et le comportement décrit plus haut pour le cas général s'appliquera donc.

courier / webmail / relais SMTP

Le POP, l'IMAP, le webmail et le relais SMTP utilisent tous le service d'authentification de courier ; il suffit donc que franGiPane ne lui montre que les comptes dont le domaine a mail_status='on'.

Listes

Cf MailingLists.

Limitations du modèle

  • franGiPane ne permet pas d'utiliser des serveurs MX secondaires.
  • Il n'est possible de créer des adresses email que @ la racine d'une zone DNS (qu'elle soit hébergée par nous au niveau DNS, ou qu'elle nous soit déléguée).
  • Il est possible de créer une adresse @ un domaine y compris si :
    • on gère le DNS de ce domaine et on fait pointer les mails ailleurs (A ou MX) : ça peut être pratique lors d'une migration, pour créer les boîtes avant de supprimer le MX qui pointe vers un autre serveur ;
    • on ne gère pas le DNS de ce domaine, et les mails pointent ailleurs (A et/ou MX) ; tant pis ?
  • Il n'est pas possible de remplir la table relocated de Postfix. C'est un peu dommage, vu que cette fonction a l'air assez chouette, mais bon, personne ne la connaît, d'une part, et d'autre part, ça complique pas mal.