Ne jamais oublier le
'/var/lib/mailman/bin/check_perms -f'
Et de redemmarer les interfaces.
Pour que mailman fonctionne bien, il va falloir commenter une variable:
Sinon il donne l'erreur:
"Cannot chdir to script directory (/usr/lib/cgi-bin/mailman/admin)" http://forum.nginx.org/read.php?2,227508,227529#msg-227529
Dans '/etc/nginx/fastcgi_params' :
# fastcgi_param SCRIPT_FILENAME $request_filename;
Ensuite avec le simple fichier de sites-available ça devrait bien marcher.
Il faut éditer
nano /etc/mailman/mm_cfg.py
Et modifier en https:
DEFAULT_URL_PATTERN = 'https://%s/cgi-bin/mailman/'
TODO
A l'air compliqué, il y a pourtant le droit d'execution pour list (bien que pas celui de www-data) sur 'private'.
'ls -la /var/lib/mailman/archives'
Il a simplement fallut faire un chmod qui donne les droits en écriture, parce que même si les fichiers appartenaient au groupe list l'owner était le root.
Ici on ne parle plus de Nginx ou de Postfix, ni même de Mailman, mais de comment chaque liste est configurée en interne: http://wiki.list.org/DOC/Making%20Sure%20Your%20Lists%20Are%20Private
Il peut y avoir un problème pour envoyer un mail à une liste. Quand la liste peut envoyer les mails, mais qu'il sest impossible de lui envoyer.
Dans notre cas l a été possble de fare une “rustine” en créant un user du même nom que la liste.
Le nom de domaine n'est pas le mee que celui du serveur, il est probable que le fichier /etc/postfix/transport fasse son effet. En prenant le mail destné à l'user et en le faisant passer à mailman.
Mais pour que postfix veuill bien le prendre, tant qu'il n'y a pas le nom d'user dans le /etc/passwd il ne lui passera pas.
Lui suggère que parfois pour qu'un nom de domaine fqdn fonctionne il faut qu'il y ait un alias postmaster pour ce nom de domaine précis:
NB: nom de l'erreur: “Postfix mailman “User unknown in relay recipient table” ”
Après en installant bien les aliases de mailman dans le main.cf du postfix, ça marche très bien.
% bin/arch newname
dans
https://www.gnu.org/software/mailman/faq.html
Le résultat est que des abonnés vont être supprimés de manière aléatoire de manière assez imprévisible, toujours à 9h00 du matin. Lui c'est 200 membres qui ont sauté d'un coup:
https://osdir.com/ml/mailman-users/2010-05/msg00109.html
http://grokbase.com/t/python/mailman-users/067nqmwgzj/list-automatically-removing-users http://grokbase.com/t/python/mailman-users/093tg69hkz/strange-bounce-removal-issue
Expliqué ici: https://www.esosoft.com/support/mailinglist/mailman/bounce.html
Mailman gère les bounces, ce que ne font pas d'autres listes. C'est au niveau des scores qu'il faut voir ce qu'il se passe. Là même explication est sur cette page de l'interface de gestion de la liste: https://lists.labx.fr/cgi-bin/mailman/admin/membres/bounce
Un moyen d'être tranquille est de diminuer ce paramètre là, de manière à remettre le compteur à zéro après 1 jour sans problèmes. Il ne restera que les adresses vraiment toxiques pour être jetées.
https://lists.labx.fr/cgi-bin/mailman/admin/ateliers_cli/?VARHELP=bounce/bounce_info_stale_after https://www.gnu.org/software/mailman/mailman-admin/node25.html
=> on met cette valeur à 1 en attendant mieux...
Et il faut trouver un moyen de le mettre en paramètre par défaut. On augmente aussi le score à dépasser à 15.0 Ce qui veut dire qu'il faudrait une adresse qui rebondissent pendant 15 jours d'affilés pour être désactivé. Les admins de liste vont en prendre plein la tête, mais ça devrait donner un répit aux abonnés.
Pour les listes qui seront crées prochainement. La variable s'appelle DEFAULT_BOUNCE_INFO_STALE_AFTER , elle se trouve dans un fichier qui n'est pas dans /var/lib, mais dans /usr/lib .
# nano /usr/lib/mailman/Mailman/Defaults.py
On a aussi bougé le fait que les listes ne soient pas publiques par défaut. Par contre c'est un remède passager, en fait il faudrait rajouter les modifications que l'on fait dans le mm_cfg.py. Donc probablement pour des variables qui ne sont présentes les rajouter à la main Parce que le Default.py sera écrasé à la prochaine mise à jour:
http://wiki.list.org/DOC/4.21%20Why%20make%20changes%20in%20mm_cfg.py%20NOT%20Defaults.py%20%3F
Un argument pour le mettre le plus bas possible, c'est quand on veut être sur que les gens aient reçu le message:
https://mail.python.org/pipermail/mailman-developers/2006-May/018769.html
NB: Ce n'est pas le cas à l'heure actuelle, mais il est possible
Ici une histoire complexe avec yahoo.com
http://grokbase.com/t/python/mailman-users/1031hjntnr/unexplained-unsubscribes-of-yahoo-com-email-addresses
Là un argument pour ne pas abonner entre elles plusieurs listes: http://grokbase.com/t/python/mailman-users/075j4re6qj/suprised-unsubscribes