Un énorme tuto de setup mail, beaucoup trop de composants pour moi mais ça peut donner des idées jusqu'où une config du genre peut aller. Y'a vraiment de tout : SPF/DKIM/DMARC ; spamassassin/clamav ; rainloop/postfixadmin, le tout basé sur des virtual-host et des virtual-users dans une base MySQL. Et ce pour du Debian 7 ET 8.

Doc de config SSL pour dovecot qui juste marche. On peut utiliser le même certif que pour postfix, par exemple celui généré par le paquet ssl-cert. Et perso j'ai mis ssl=required :-'

Faire passer l'auth SASL de postfix directement par dovecot (comme ça, un seul endroit où configurer l'auth). Attention au distingo "smtpd_recipient_restrictions" et "smtpd_relay_restrictions" qui doivent être tous deux configurés pour laisser passer les utilisateurs SASL (soit globalement dans main.cf soit uniquement pour le port de soumission (587), dans master.cf).

Quand ça veut pas entre dovecot et PAM, il suffit de mettre l'authentification en verbeux et de voir que c'est pas le bon nom qui est vérifié (il y a le nom de domaine dedans, comme pour une config en virtualhost).
auth_username_format = %Ln

… et quand le serveur en face veut pas de startssl, bah on a quand même besoin de AUTH_CLIENT_ALLOW_NOTLS_PASSWORDS :)

Dans ce rapport il y a aussi une commande super pratique pour debug :
echo blah | exim4 -d+all some@adress
qui permet de faire un run debug en live, sans l'activer dans le daemon. On a donc tout le détail de ce qu'il se passe, sans polluer de log ou devoir reload.

Bah voila des commandes sympa avec exim :)
C'est mignon les trucs comme exiwhat, exiqsumm etc.

La flemme de configurer un vhost pour la liste mailman interne, et fait un test au début qui rappelle tous les jours qu'il faut s'occuper de lui ? 'bin/discard' est ton ami. :)
J'avais juste supprimé le fichier "heldmsg-mailman-1" comme indiqué ailleurs mais ça ne suffit pas, il reste dans les pending ou les requests (ici c'était un request car envoyé d'une adresse pas abonnée). Pour voir le contenu des attentes :
sudo /usr/lib/mailman/bin/dumpdb /var/lib/mailman/lists/mailman/{request,pending}.pck

Une seule commande pour renew le certif SSL d'exim :
/usr/share/doc/exim4-base/examples/exim-gencert --force
Pas besoin de lancer la commande openssl donnée à la main : le script le fait.

À noter que ce sera (forcément) un certif auto-signé, et qu'il est créé pour 3 ans.

« When running in screen, transparency does not work, and there are trailing spaces filling every line when cut-and-pasting »
« Add the following to your ~/.screenrc and restart screen:
defbce on
term screen-bce
»
Et hop plus d'emmerde à C/C depuis les mails. Si on a la flemme de relancer screen (irssi qui tourne par exemple :P) on peut même le faire directement, le defbce comme commande screen et avec la variable d'env TERM :
export TERM=screen-bce

Jouer avec un certificat SSL serveur, ça pète une semaine plus tard… et dans un autre service, oups. Le topo :

Les mails StrasWeb étaient en rade ; explications :

• Le serveur a reboot (!)
• On a joué avec le certificat SSL (pour mumble, samedi)
• OpenDKIM l'utilise et aimait pas les permissions
• postfix appelle OpenDKIM à tous les traitements

Et paf les mails, sans qu'on n'en sache rien… oups.

Pour la postérité, les messages d'erreurs sont :
connect to Milter service inet:127.0.0.1:8891: Connection refused
Starting OpenDKIM: opendkim: /etc/opendkim.conf: /etc/apache2/server.key: key
data is not secure

Alors oui ok OpenDKIM qui tape dans le certif chez apache c'est pas top…

J'ai fait un petit setup de test, ça marche plutôt pas mal a priori. Par contre dans mon test j'ai laissé le MTA poser les nouveaux mails dans /new du Maildir lui-même, et du coup dovecot ne réagissait pas et ne lançait pas la réplication… en basculant sur du LMTP c'est bon (LDA aurait probablement suffit). Pourtant il semblerait que dovecot utilise inotify mais peut-être pas pour ça.