Introduction
Voir les principes généraux de messagerie à l'auf.
Les besoins
- 3 domaines à gérer: td.refer.org et td.auf.org et td.auf
- td.auf.org: comptes locaux du personnel, de communication (info, cnf, etc), des mailing-lists du cnf, etc
- td.auf: comptes mail associés aux services (logcheck, cron, etc) tournant sur les serveurs
- td.refer.org: comptes des usagers du campus, de communication (info, cnf, etc), des mailing-lists du cnf, des institutions partenaires (universités, facultés, etc)
le personnel reçoit les emails sur les deux domaines: si untel est un employé auf, alors untel@td.auf.org == untel@td.refer.org. C'est pour prendre en compte le fait que le serveur de mail de montreal me renvoie les mails concernant le personnel en @td.refer.org et non @td.auf.org comme je l'aurai pensé.
- les adresses de communication sont par défaut en td.auf.org
pour le reste, les namespaces des deux domaines sont disjoints (untel@td.auf.org <> untel@td.refer.org).
les emails du personnel sont reçus et transmis sur Internet après conversion: perso@auf.org <-> perso@td.auf.org
- les comptes associés aux services tournant sur les serveurs internes ne doivent pas être authentifiés lors de l'envoi de courriers (smtp).
les comptes associés aux services tournant sur les serveurs internes ne doivent pas pouvoir envoyer des courriers à un usager autre que root@td.auf.org (en d'autres termes, tout courrier en @td.auf ne peut écrire qu'à @td.auf.org) et ne peuvent pas se connecter en IMAP.
- pas de compte unix locaux pour les utilisateurs mail
- mettre en place un système antivirus/antispam/greylisting/blacklisting
- pas d'interface web sur le serveur mail. Le webmail sera installé sur le serveur web et communiquera via IMAP avec le serveur mail.
- mettre en place un système permettant aux utilisateurs de modifier leur mot de passe sans passer par l'administrateur (pas d'interface web): un mail vers une adresse d'administration par exemple? (todo)
- transmission cryptée des mots de passe
- possibilité des usagers d'envoyer des emails avec leur compte @td.{auf,refer}.org depuis n'importe où sur Internet
- prendre en compte les aspects sécurité
- prendre en compte les règles antispam dictées par les utilisateurs (todo)
- centraliser dans ce serveur, les mails générés par tous mes serveurs. Chaque mail devra pour permettre l'identification du serveur source. (todo)
- suivre les recommendations AUF
II- Description de la solution
- mise en place de mailbox virtuels
- système d'authentification non classique (/etc/passwd, /etc/shadow). Il faut trouver une alternative: sql, fichiers, ldap
- système d'authentification par fichiers préféré: nombre peu élevé d'utilisateurs, économie des ressources serveurs, performances, facilité de gestion?
- réécriture canonique/virtuelle des adresses du personnel:
à l'émission (perso@td.{auf, refer}.org -> nom.prenom@auf.org)
à la réception (nom.prenom@auf.org -> perso@td.auf.org)
untel@td.auf.org et untel@td.refer.org auront deux boîtes mail distinctes. On peut tendre vers un système de stockage semblable à celle-ci:
---- perso1
|
|
--- td.auf.org ------------------------|--- perso2
| |
| |
| ---- etc
|
(mailbox_base) ------------------|
|
| ---- untel1
| |
| |
--- td.refer.org ----------------------|--- untel2
|
|
---- etcles adresses de communication (les listes de diffusion incluses) sont donc stockés dans la partie td.auf.org, mais appartiennent aux deux domaines. Ainsi, l'adresse d'information du campus peut être indifféremment info@td.auf.org ou info@td.refer.org. Cela peut se réaliser par les mappings suivants:
comm@td.auf.org td.auf.org/comm
comm@td.refer.org td.auf.org/comm- les comptes du personnel doivent appartenir aux deux domaines. On doit donc avoir des mappings comme suit pour tous les comptes du personnel:
perso@td.auf.org td.auf.org/perso
perso@td.refer.org td.auf.org/perso- les personnes externes (usagers, adresse mail de personnel d'université, etc) sont exclusivement accessibles via les adresses du domaine @td.refer.org
- les adresses associés aux services tournant sur les serveurs seront exclusivement du ressort du domaine @td.auf (vu qu'il ne communiquent pas avec l'extérieur).
- td.refer.org et td.auf.org seront considérés comme domaines virtuels puisqu'on ne stocke pas les comptes via des comptes unix locaux.
- ne pas créer des utilisateurs virtuels (entrée dans la bd des utilisateurs) pour les comptes associés aux services systèmes.
- restreindre la liste des usagers habilités à envoyer des mails à l'extérieur via le serveur qu'aux usagers authentifiés sasl. Mais comment restreindre à l'envoie uniquement à root@? TODO.
Mise en oeuvre
configuration de base
# banniere affichee par le serveur smtpd_banner= $myhostname ESMTP CNF-TD biff=no # laisse le soin aux MUA d'ajouter le "." aux noms de domaines append_dot_mydomain = no # nom du serveur myhostname = mail.td.auf.org #domaine attribue aux mails sortant - voir plus bas pour les reecritures # des adresses sortantes utilisant les domaines virtuels: myorigin = localhost # alias alias_maps = hash:/etc/aliases alias_database = hash:/etc/aliases # clients locaux mynetworks = 127.0.0.0/8, 10.204.0.0/16, 192.168.0.0/16 # relay? no relayhost = # pas de quota - les boites emails sont illimitees en taille mailbox_size_limit = 0 # boites mails au format Maildir home_mailbox = Maildir/ # autres parametres recipient_delimiter = + # ecoute sur toutes les interfaces inet_interfaces = all # je me prepare a accepter les mails via IPv6 un jour ;-) # inet_protocols = all
Création des boîtes mail pour les comptes virtuels
Principe: on va créer un utilisateur qui sera dédié à la gestion des mails reçu par le système. Il sera donc propriétaire de tous les mails.
# sudo groupadd -g 5000 vmail # sudo useradd -m -u 5000 -g 5000 -s /bin/bash vmail
Note: je me demande si je dois pas changer le shell de cet utilisateur pour /usr/sbin/nologin
Mise en place des comptes virtuels dans la config postfix
# domaines virtuels servis par ce serveur virtual_mailbox_domains = /etc/postfix/virtual/domains # repertoire de base pour le stockage des mails virtual_mailbox_base = /home/vmail # mapping adresse <-> boite-mail # Exemple: # info@td.refer.org td.refer.org/info (voir diagramme plus haut) # la boite-mail = $virtual_mailbox_base/td.refer.org/info virtual_mailbox_maps = hash:/etc/postfix/virtual/mailboxes #uid mini pour l'utilisateur proprietaire des emails - pas vraiment utile virtual_minimum_uid = 1000 # utilisateur proprietaire des emails virtual_uid_maps = static:5000 virtual_gid_maps = static:5000
Contenu de virtual/domains:
td.auf.org td.refer.org
Contenu de virtual/mailboxes (exemple)
nacer@td.auf.org td.auf.org/nacer nacer@td.refer.org td.auf.org/nacer info@td.auf.org td.auf.org/info info@td.refer.org td.auf.org/info recteur-univ@td.refer.org td.refer.org/recteur-univ usage-cnf@td.refer.org td.refer.org/usager-cnf ...
et je crée la bd (le 'hash' m'y oblige) correspondante:
# cd virtual; postmap mailboxes; invocke-rc.d postfix reload
Les correspondances
L'une des contraintes à satisfaire est de s'assurer que tous les mails adressés aux personnels auf de mon implantation soit bien acceptés (par exemple, si xxx.yyy@auf.org => <nom local>@td.auf.org). De plus, tous les mails sortant du serveur doivent être en @auf.org. Pour cela,j'utilise une table de réécriture canonique:
# sender_canonical_maps = hash:/etc/postfix/virtual/sender-canonical-auf # recipient_canonical_maps = hash:/etc/postfix/virtual/recipient-canonical-auf
et bien sûr ceci n'est vrai que si on est connecté via le réseau interne ou via sasl:
# local_header_rewrite_clients = permit_mynetworks, permit_sasl_authenticated
Note: je me demande si le permit_sasl_authenticated est vraiment nécessaire.
Contenu des tables(exemple):
# sender-canonical-auf: nacer@td.auf.org nacer.saidou-adamou@auf.org nacer@td.refer.org nacer.saidou-adamou@auf.org
et
# recipient-canonical-auf: nacer.saidou-adamou@auf.org nacer@td.auf.org
TO BE CONTINUED