Gérer ses mailing list avec mailman

Copier la conf d'une ML

Vous avez passé des mois à configurer tip-top bien les options d'une mailing list (abrégé ML dans la suite :p ) et vous souhaitez utiliser cette même conf dehouf sur vos autres ML ? y'a pas d'option directe possible, cependant il suffit de ruser en exportant la configuration de votre première ML, puis de la modifier avant de l'importer sur votre autre ML :

  • export de la configuration de la ML nommée ma-mailing-list dans le fichier /tmp/config_ma-mailing-list.txt :
    /usr/lib/mailman/bin/config_list -o /tmp/config_ma-mailing-list.txt ma-mailing-list
  • modification de ce fichier au besoin : il vous faudra certainement au moins modifier le champs “nom_reel”. J'utilise VIm mais ici chacun sa religion : vous êtes libres d'utiliser des éditeurs inférieurs
  • Il ne reste plus ensuite qu'a assigner cette configuration à notre autre ML :
    /usr/lib/mailman/bin/config_list -i /tmp/config_ma-mailing-list.txt mon-autre-mailing-list

Peupler une ML

Pour peupler une ML on peut utiliser un fichier. Deux des formats possibles vont nous intéresser :

  • soit une adresse mail par ligne (facile :p)
  • soit un champs libre que nous pourrons positionner a “NOM Prénom” suivi de l'adresse mail entre chevrons, comme par exemple (la encore une ligne par membre) :
    DERAIE Odile <odile@mondomaine.com>

Fort d'un fichier /tmp/liste_membres_ml2houf.txt formaté comme décrit ci dessus, pour faire les ajouts à la ML ml2houf sans envoyer de message de bienvenue (-w n) ni notifier l'admin (c'est nous ;p) de ces ajouts (-a n) il faut utiliser la commande add_members :

/usr/lib/mailman/bin/add_members -w n -a n -r /tmp/liste_membres_ml2houf.txt ml2houf

Dire a mailman de ne pas grouper les envois par domaine

Par défaut mailman essaye de grouper les envois par domaine pour optimiser les ressources. Si votre mailman n'est pas surchargé vous préférerez certainement ne pas grouper les mails pour avoir une gestion plus fine des adresses en erreur ou non (et que les 9 destinataires d'un message le reçoivent même si le 10e destinataire a une adresse invalide :p)

pour se faire cela se passe dans le fichier /etc/mailman/mm_cfg.py : ajouter la directive SMTP_MAX_RCPTS :

# Max recipients for each message
SMTP_MAX_RCPTS = 1

Mailman et DKIM

DKIM est de plus en plus employé dans les infrastructures de mail (yahoo, gmail, sfr, …), ce qui est tres bien … sauf pour mailman. En effet mailman fait de base 2 choses qui invalident la signature du mail :

  • modifier le sujet pour ajouter une préfixe type [coincoin]
  • ajouter un footer permettant de se désabonner

A l'heure actuelle ne pas avoir de DKIM est moins pire que de déclarer signer ses mails alors que cette signature n'est plus valide en sortant de mailman : pour cette dernière raison pas mal de domaines de vos abonnés vont considérer que les envois de vos mailing-list sont du spam et vont même aller plus loin : jeter ce mail sans autre forme de procès et sans bien sur notifier qui que ce soit (pas le destinataire ni même l'expéditeur)

Moralité, 3 choix :

  • virer la signature DKIM des mails entrants, ce qui marche tant que la signature n'est déclarée pas obligatoire sur le domaine de l'expéditeur
  • trouver un moyen de faire une chaine de confiance entre le domaine de l'expéditeur et celui de mailman, par exemple via https://sites.google.com/site/oauthgoog/mlistsdkim et la notion de trust forwarder. ca serait très bien si c'etait réellement implémenté mais ça ne l'est pas a l'heure actuelle (03/04/2015, mailman debian wheezy 2.1.15)
  • juste ne plus modifier le sujet/corps du mail

J'ai choisi de faire la 3e, pour se faire, via l'interface web d'admin de la ML :

  • aller dans les options de remise non groupé (non-digest pour les anglophones) et enlever le contenu de l'option msg_footer
  • aller dans les options générales et enlever le contenu de l'option subject_prefix
Du coup le lien de désabonnement ne sera plus dans chaque mail. Vu le nombre de gens qui l'utilisent réellement pour se désabonner au lieu d'envoyer un mail à tous pour faire travailler l'admin ça ne devrait pas poser trop de problemes. Au pire il reste la solution de continuer à envoyer les reminder d'abonnement mensuels de mailman
sysadmin/tips/mailman.txt · Dernière modification: 2015/04/03 13:06 par james
Driven by DokuWiki Recent changes RSS feed Valid CSS Valid XHTML 1.0