Re: [sympa-fr] Possibilité LMTP entre serveurs Sympa et IMAP

[Laurent Spagnol <adresse@cachée>]

Directement avec LMTP, c'est tout à fait possible.

Par défaut, lmtpd va demander une authentification au serveur qui lui 
soumet des messages (via une socket réseau c'est certain, via une socket 
Unix je ne sais pas, faut essayer). Du coup, soit tu gère une 
authentification côté MTA du serveur Sympa, soit tu ajoute l'option "-a"
dans cyrus.conf ...

Si tu lis la doc du démon lmtpd de Cyrus:

"-a Preauthorize connections initiated on an internet socket, instead of 
requiring LMTP AUTH.  This should only be used for connections coming 
from trusted hosts."

Ce qui signifie qu'avec cette option, c'est "open-bar" ... le seul 
garde-fou ce sont des ACLs réseau (firewall central et/ou Netfilter sur 
le serveur Cyrus). Le coup de la boulette sur le firewall central qui 
ouvre les accès au monde entier, j'ai déjà eu ... donc je fais hyper 
gaffe à mes configs et j'ai des mécanismes de contrôle (notamment 
"accounting") un peu partout.

Pour cette raison, si j'utilise LMTP via une socket réseau, je le fais 
uniquement en "loopback". Si je suis en mode "réseau" et pas en "socket 
Unix", c'est pour ne pas me battre avec les "chroots" et les droits 
d'accès !

Bref, LMTP entre serveurs, je ne suis pas fan. Je préfère SMTP "bretelle 
et ceinture": je met des ACLs Netfilter sur le serveur IMAP et je cumule 
avec des restrictions applicatives côté Postfix. En fait, les seules 
machines qui ont le droit d'envoyer des messages aux spoolers IMAP sont:
- les serveurs du cluster anti-spam (passage obligatoire pour TOUS les 
mails)
- les serveurs de listes (un serveur Sympa et un autre pour les "codes 
étapes" basé uniquement sur des aliases récursifs), et je précise que 
tout ce qui sort des serveurs de listes est forcément passé par l'anti-spam.
- les serveurs IMAP eux-même pour les "forwards internes" (qui sont très 
"réglementés"

Note au sujet du forward: en interne ça ne pose généralement pas de 
problème technique. Par contre le forward "inter domaines" c'est le mal 
absolu. Pratique qui avait du sens il y a 10 ans, mais avec la 
généralisation de SPF, DKIM, DMARC, S-MIME et compagnie on n'a plus qu'à 
expliquer aux utilisateurs que cette pratique à toutes les chances 
d'aboutir à des rejets de messages. Donc chez moi, c'est tout simplement 
exclu !

Soumettre au spooler IMAP via SMTP plutôt que LMTP, c'est pas un 
problème: ça ne gêne en rien la déduplication, ça fait juste une ligne 
de plus dans les entêtes, et je trouve ça juste plus simple et plus 
"secure".

Après, si tu as des problèmes lors des diffusions massives, tu peux 
contrôler la cadence de livraison. Je fais ça côté Sympa ET côté IMAP.

Le but n'est pas de tout livrer en un minimum de temps (des posts à 
plusieurs dizaines de milliers de destinataires, c'est courant) mais de 
faire en sorte que le MTA du serveur IMAP ne fasse pas monter les IOPs 
jusqu'à écrouler la machine !

Sinon, pour l'acheminement depuis le serveur Sympa, je fais tout avec 
des tables de transport. Les tables d'aliases sont réservées aux 
adresses locales (donc les files sympa) et un truc que j'ai bricolé pour 
avoir des répondeurs sur les listes. Je n'utilise pas les tables 
"virtual" dans ce contexte.

Voilà, il y a plein de façons de faire: les possibilités de Postfix sont 
énormes.

J'ai donné ma recette de cuisine (qui fonctionne). Certains n'aimeront 
peut-être pas le goût. Libre à chacun de faire ses propres choix, de les 
tester (tu as beau lire la doc, c'est souvent utile de tester pour bien 
comprendre ...), les valider et les mettre en prod.

Cdlt,

LS


Le 30/01/2019 à 12:57, Ismaël Tanguy a écrit :
> Bonjour Laurent,
>
> merci beaucoup pour tes indications, le hors-sujet m'intéresse 
> particulièrement!
> On compte justement mettre à jour Postfix/Cyrus et se servir de 
> nouvelles fonctionnalités.
>
> Le MTA sera découplé de Cyrus  (LMTP entre eux) et on pourrait atteindre 
> aussi directement Cyrus avec le Postfix de Sympa et LMTP sans passer par 
> le MTA
>
> Un truc du style:
>
> main.cf de Sympa:
>
> local_transport: lmtp:inet:<CYRUS IMAP>:<PORT>
> local_recipient_maps: map ldap avec un mailForwardingAddress vers MON 
> DOMAINE
>
> virtual_alias_map: map ldap avec les redirections vers d'autres domaines
> virtual_transport: lmtp:<MTA>:<PORT>
>
> Ainsi, on pourrait éviter que les mails à destination de notre domaine 
> passent dans un second MTA avant d'être délivré à Cyrus
>
> Dans la doc Cyrus:
>
> /If a delivery attempt mentions several recipients (only possible if the 
> MTA is speaking LMTP to //lmtpd//), the server attempts to store as few 
> copies of a message as possible. It will store one copy of the message 
> per partition, and create hard links for all other recipients of the 
> message.
> /
>
> LMTP semble suffisant pour que la déduplication soit effective.
>
> Qu'en penses-tu?
> Je vois quelquefois que notre Postfix traine un peu quand on a plein de 
> mails de Sympa dans son mailqueue.
>
> Bonne journée,
> Ismaël TANGUY
>
> <http://www.univ-brest.fr>
>
>
> Le 30/01/2019 à 11:58, Laurent Spagnol a écrit :
> > Bonjour,
> >
> > LMTP n'est pas nécessaire et c'est finalement moins simple à 
> > configurer que SMTP dans ce cas d'usage.
> >
> > La déduplication de Cyrus peut parfaitement fonctionner avec SMTP !
> > Si le MTA (Postfix j'imagine) de ton spooler Cyrus est déjà configuré 
> > pour la déduplication, il n'y a rien de plus à faire côté MTA de Sympa.
> >
> > # Cyrus single instance message store:
> > # The postfix local transport always breaks up multiple recipient
> > # messages into single messages for delivery.  If you want to use single
> > # message store, you can't use the local transport for your main
> > # delivery. Mailbox_transport is part of the local transport.
> > # If you really need local transport features, you can use the virtual
> > # alias system to forward mail to a subdomain.
> >
> > En gros, côté Cyrus, il ne faut pas utiliser la table d'aliases mais 
> > une table "virtual". Ce qui donne chez moi (à titre d'exemple):
> >
> > *** Dans "main.cf"
> >
> > local_destination_concurrency_limit = 1
> > default_destination_recipient_limit = 500
> > local_transport = lmtp:inet:localhost:2003
> > virtual_maps =
> > hash:/var/lib/tsync-master/virtual_map.ldap_mailForwardingAddress,
> >         hash:/var/lib/tsync-master/virtual_map.aliases_generiques,
> >         hash:/var/lib/tsync-master/virtual_map.ldap_mail,
> > hash:/var/lib/tsync-master/virtual_map.ldap_mailAlternateAddress,
> >         hash:/var/lib/tsync-master/virtual_map.ldap_supannEmpId,
> >         hash:/var/lib/tsync-master/virtual_map.local_mbox
> >
> > *** Dans "cyrus.conf" (note que "lmtpd -a" est nécessaire, il a donc 
> > plutôt intérêt à n'écouter que sur l'adresse loopback ...)
> > # UNIX sockets start with a slash and are put into /var/imap/socket
> > SERVICES {
> >
> >   lmtp          cmd="lmtpd -a" listen="localhost:2003" proto="tcp4"
> >   imap          cmd="imapd" listen="imap" proto="tcp4" maxchild=-1
> >   pop3          cmd="pop3d" listen="pop3" proto="tcp4" maxchild=-1
> >   sieve         cmd="timsieved" listen="sieve" proto="tcp4" maxchild=-1
> >
> > }
> >
> > *** Dans "imapd.conf"
> >
> > # Activer la dédup par liens durs
> > singleinstancestore: yes
> >
> > Tant que j'y suis, quelques "tips" pour imapd.conf (là, je sors du 
> > cadre de la liste ...).
> >
> > # Supprimer les doublons, par exemple si un utilisateur
> > # est 2 fois destinataire du même message (une fois via adresse 
> > nominative et un fois via abonnement à une liste), il n'aura qu'un 
> > seul exemplaire
> > duplicatesuppression: 1
> >
> > # Indiquer aux clients lourds (Thunderbird et Outlook) quels sont les 
> > noms des dossiers. Je met la même chose côté Webmail comme ça tout est 
> > mappé correctement. Il n'y a que chez Apple qu'on ne fait pas comme 
> > tout le monde ...
> > # Special-Use Mailboxes. Use xlist- prefix to the list of special use
> > # attributes defined in RFC 6154. Attribute name in the configuration
> > # key should be defined in lowercase. The attribute value is case
> > # sensitive, may contain whitespace and and must be valid
> > # UTF7-IMAP string.
> > xlist-archive: Archives
> > xlist-drafts: Drafts
> > xlist-sent: Sent
> > xlist-spam: Junk
> > xlist-trash: Trash
> >
> > # Un truc qui permet d'améliorer considérablement les perfs, surtout 
> > si tu travailles avec des disques à plateau => placer certaines bases 
> > qui peuvent être "perdues" en RAM !
> > proc_path: /var/imap/tmpfs/proc
> > mboxname_lockpath: /var/imap/tmpfs/lock
> > duplicate_db_path: /var/imap/tmpfs/duplicate.db
> > statuscache_db_path: /var/imap/tmpfs/statuscache.db
> >
> > Toujours du côté "optimisations", je ne peux que recommander 
> > chaudement ce module "pam_cas patché": les tickets sont stockés dans 
> > de bêtes fichiers, du coup plus de problèmes de cache et d'expiration 
> > (qu'on a forcément même avec la version patchée du cache "sasl" ...
> >
> > J'en avait rêvé mais je ne suis pas capable de le coder. Des collègues 
> > l'ont fait. Big-up et super-grand-merci les gars !!! :)
> > => https://github.com/EsupPortail/esup-pam-cas
> >
> > Toujours côté optimisations, je stocke aussi les tickets en RAM.
> > Et contre toute attente, j'utilise aussi le cache SASL (mais la 
> > version "normale" de la distribution): les requêtes dans le cache SASL 
> > sont plus rapide que la recherche d'un fichier (même en RAM), si la 
> > donnée n'est pas dans le cache SASL, il ira chercher dans le cache du 
> > module pam_cas.
> >
> > Ce qui donne côté config:
> >
> > *** /etc/default/saslauthd
> > MECHANISMS="pam"
> > OPTIONS="-t 900 -s 8192 -c -m /var/run/saslauthd"
> >
> > *** /etc/pam.d/imap
> > auth    sufficient      pam_ldap.so
> > auth    sufficient      /usr/local/pam_cas/pam_cas.so 
> > -simap://FQDN_SERVEUR_IMAP -f/etc/pam_cas.conf
> > auth    required        pam_deny.so
> >
> > *** /etc/pam_cas.conf
> > host cas.univ-reims.fr
> > port 443
> > uriValidate /cas/proxyValidate
> > ssl on
> > cacheDirectory /var/cache/pam_cas
> > trusted_ca /etc/ssl/certs/ca-certificates.crt
> >
> > *** /etc/pam_cas_expire.conf
> > # durée maximale d'une session (minutes), 0=illimité
> > cacheLifetime=480
> >
> > # durée d'expiration sur inactivité (minutes), 0=illimité
> > cacheTimeout=0
> >
> > # pam_cas config file location
> > pamCasConf="/etc/pam_cas.conf"
> >
> > *** /etc/imapd.conf
> > # 2 sources spécifiées:
> > # - sasl pour l'auth via PAM donc LDAP et CAS
> > # - auxprop pour quelques comptes "locaux" (base SASLDB) qui ne sont 
> > pas dans LDAP
> > sasl_pwcheck_method: auxprop saslauthd
> > sasl_auxprop_plugin: sasldb
> >
> > Cdlt,
> >
> > LS
> >
> >
> >
> > Le 30/01/2019 à 11:10, Ismaël Tanguy a écrit :
> > > Bonjour à tous,
> > >
> > > actuellement, nous envoyons les mails de Sympa à notre serveur SMTP 
> > > qui s'occupe soit de les envoyer ailleurs pour les abonnés 
> > > extérieurs, soit de les envoyer vers notre serveur IMAP.
> > >
> > > Est-ce que certains d'entre vous utilisent le Postfix de Sympa pour 
> > > envoyer directement en LMTP vers IMAP les mails destinés à leurs 
> > > utilisateurs?
> > >
> > > Pour l'instant, je me dis que le Postfix de Sympa doit pouvoir 
> > > résoudre les alias et connaître les redirections en place pour faire 
> > > cela.
> > >
> > > J'y vois 2 intérêts:
> > >
> > > - décharger le serveur SMTP
> > > - mieux gérer la déduplication des mails sur le serveur IMAP, par 
> > > exemple cyrus peut créer des hard link des mails identiques obtenus 
> > > par LMTP afin de sauver du stockage, paramètre single-instance store.
> > >
> > > Merci pour vos réponses,
> > > Ismaël Tanguy
> > >
> > > --
> > > <http://www.univ-brest.fr>

--
Laurent Spagnol
Administrateur GNU/Linux

Responsable du pôle système
Service réseau et télécom
Direction du Numérique

Université de Reims
Campus du Moulin de la Housse
Bâtiment 3
BP 1039 - 51687 Reims cedex 2

Plan d'accès : https://frama.link/DN-URCA

Tel: +33 3 26 91 88 32
Fax: +33 3 26 91 31 87

https://numerique.univ-reims.fr