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

[Ismaël Tanguy <adresse@cachée>]

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

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>