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

[Laurent Spagnol <adresse@cachée>]

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