Ubuntu
ApacheDockermailmanPostfix

Ubuntu20.04 Mailman3でマルチドメインなメーリングリスト 前編

現在、個人用・公開用の2ドメインを運用し、それぞれメールサーバーも運用している。
この2つのドメインを一手に引き受けるメーリングリストを作ることはできないものか、と考えた。



広告

イマドキはチャットで連絡をすることが多くなってきているけれども、チャットほど濃くない、緩いつながりもいい。

今回は記事がとても大きくなってしまったので、前編・後編と分けてみた。
Mailman3はDockerイメージを使っており、設定自体は前編でほぼ完了するので、これだけで使い始められるかもしれない。
後編では、メールメッセージの日本語化や、マルチドメインならではのメール転送、テスト環境のPostfixにSMTP認証を入れること等を取り扱っている。

環境

ドメインは、rohhie.netとmyhome.local(名前はマスク)の2つを運用している。
これらのメールサーバーとは別のホストwork.hogeserver.hogeddns.jpに、Mailman3でメーリングリストを実装する。

Postfixはすべてのホストにインストール済みで、ローカル内の各ホスト間でメールがやりとりできるところまでテスト済み。

ホストドメインOS説明
work.hogeserver.hogeddns.jpマスクしたものUbuntu 20.04 LTS今回構築し、メーリングリストを管理・運用する。
rohhie.net実在Ubuntuメーリングリストml-theme@rohhie.netを運用したい。
myhome.localマスクしたものUbuntu家族連絡用のml-info@myhome.localを運用したい。

結論からすると、サブドメイン(ml.rohhie.netとか、mm.myhome.localとか)を作ったり、別ドメインを作ったりした方が、圧倒的にメールに関する管理が楽。
でも、Postfixに関する知識が不足しており、学習もかねてこのテーマとした。

Mailman3のインストール

work.hogeserver.hogeddns.jpにMailman3をインストールしていく。

メーリングリストというと、Ubuntu 12.04時代にMailmanでの構築経験があった。当時、コンソールをEUCに切り替えて色々と操作をしていった記憶がある。

fmlは魅力的なんだけれども、当時は説明されていることのほとんどを(知識がないから)理解できず、断念。
一方でUbuntuにはパッケージが用意されていて、すぐに使えるっぽかったMailmanを使わせてもらった。

今回はちょっと急いでいたこともあり、Ubuntuのパッケージが用意されているMailman3を選択。
でも、それが泥沼の始まり。色々やってみた結果、Mailman3のUbuntuパッケージには問題があるらしく、インストーラーが異常終了する。
また、投稿が消えるのでソースを書き換えた…といった情報も見つかる。

最終的にDockerでMailman3を構築することにした。

Dockerのインストール

Dockerのインストールは過去に整理した手順で実行。

Dockerのインストール。

$ sudo apt install apt-transport-https ca-certificates curl gnupg lsb-release
$ curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg
$ echo "deb [arch=amd64 signed-by=/usr/share/keyrings/docker-archive-keyring.gpg] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
$ sudo apt update
$ sudo apt install docker-ce docker-ce-cli containerd.io
$ docker -v
Docker version 20.10.8, build 3967b7d

Docker Composeのインストール。

$ sudo curl -L "https://github.com/docker/compose/releases/download/1.29.2/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose
$ sudo chmod +x /usr/local/bin/docker-compose
$ docker-compose --version
docker-compose version 1.29.2, build 5becea4c

※本日の最新は1.29.2。公式の手順書は最新バージョンに追従するようになっているようなので、そこからコピーしてくるのが良いだろう。

Mailman3のインストール

公式がアナウンスしているDockerイメージを、手順が意図するところを踏まえてインストールしていく。
Github / GNU Mailman 3 Deployment with Docker

まず、ボリュームが作られるディレクトリを作成。

$ sudo mkdir -p /opt/mailman/core
$ sudo mkdir -p /opt/mailman/web

ローカルにプロジェクトファイルをダウンロードしてくる。

$ git clone https://github.com/maxking/docker-mailman
$ cd docker-mailman

データベースにはMySQLではなくMariaDBを使いたい…docker-compose-mysql.yamlがMariaDBのイメージを使っている。ラッキーだ。

構成にあたってDjangoの秘密鍵を生成しておく。
stackoverflow / Is there a function for generating settings.SECRET_KEY in django?

$ sudo apt install python3-django
$ python3
>>> from django.core.management.utils import get_random_secret_key
>>> print(get_random_secret_key())
56fn6dr53b&2icn4%&89rvirg0q@m=j9dwbr)+yoi9=-*=2hs8
>>> [Ctrl]+[D]

※printするたびに新しいキーが生成される。

docker-compose-mysql.yamlを環境に合わせて編集していく。

version: '2'

services:
  mailman-core:
    image: maxking/mailman-core:0.3
    container_name: mailman-core
    restart: always
…
    environment:
    - DATABASE_URL=mysql+pymysql://mailman:mailmanpass@database/mailmandb?charset=utf8mb4&use_unicode=1
    - DATABASE_TYPE=mysql
    - DATABASE_CLASS=mailman.database.mysql.MySQLDatabase
    - HYPERKITTY_API_KEY=KonoKeyHaDonnaMojidemoIimitai ← 任意のキーに置き換え
    - MTA=postfix
…
  mailman-web:
    image: maxking/mailman-web:0.3
    container_name: mailman-web
    restart: always
…
    environment:
    - DATABASE_URL=mysql://mailman:mailmanpass@database/mailmandb?charset=utf8mb4
    - DATABASE_TYPE=mysql
    - HYPERKITTY_API_KEY=KonoKeyHaDonnaMojidemoIimitai ← mailman-coreで定義したものと同じにする
    - SECRET_KEY=56fn6dr53b&2icn4%&89rvirg0q@m=j9dwbr)+yoi9=-*=2hs8 ←先程作ったキーに置き換え
    - DYLD_LIBRARY_PATH=/usr/local/mysql/lib/
    - SERVE_FROM_DOMAIN=rohhie.net
    - MAILMAN_ADMIN_USER=rohhie
    - MAILMAN_ADMIN_EMAIL=rohhie@rohhie.net
    - MAILMAN_HOST_IP=*
…

※MariaDBだけはスタートアップ時に起動する設定になっていた。mailman-coreとmailman-webも自動起動を設定。

mailman-webに定義したMAILMAN_HOST_IP=*は、本来は望ましくない設定のようだが、書いておかないとアーカイブにアクセスできない問題が発生する。
ただ、HYPERKITTY_API_KEYで守られているのと、発生する問題がWebアクセスできないということだけで、しっかりとアーカイブは取られているので、後から最適値を考えてもいいように思う。

この設定で起動してみる。

$ sudo docker-compose -f docker-compose-mysql.yaml up -d

これでシステムが立ち上がる。

今回のバージョンではサイトオーナーのメールアドレスが設定されなかったので、以下のやり方で設定。

/opt/mailman/core/mailman-extra.cfg ※新規作成

[mailman]
# This address is the "site owner" address.  Certain messages which must be
# delivered to a human, but which can't be delivered to a list owner (e.g. a
# bounce from a list owner), will be sent to this address.  It should point to
# a human.
site_owner: siteowner@rohhie.net

この設定は、コンテナを再起動した段階で反映される。

$ sudo docker-compose -f docker-compose-mysql.yaml stop
$ sudo docker-compose -f docker-compose-mysql.yaml up -d

ディレクトリは作ってあったので、最初にコンテナを起動する前に作っておいても動作するかもしれないが、試していない。

Apacheの設定

Mailman3のUIにアクセスするために、ApacheをインストールしてProxy設定する。
インストール後、http://work.hogeserver.hogeddns.jp/にアクセスし、デフォルトページが表示されることを確認しておく。

$ sudo apt install apache2

デフォルトで発生するエラーメッセージを回避。

$ echo "ServerName localhost" | sudo tee /etc/apache2/conf-available/fqdn.conf
$ sudo a2enconf fqdn
$ sudo apachectl configtest
Syntax OK
$ sudo systemctl reload apache2

アクセス用の設定ファイルを新しく作る。
/etc/apache2/sites-available/mailman3.conf ※新規作成

<VirtualHost *:80>
    ServerName work.hogeserver.hogeddns.jp
    RewriteEngine On
    RewriteCond %{HTTPS} off
    RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI}
</VirtualHost>

<VirtualHost *:443>
    ServerName work.hogeserver.hogeddns.jp
    ServerAdmin rohhie@rohhie.net

    ErrorLog  ${APACHE_LOG_DIR}/mailman3-error.log
    CustomLog ${APACHE_LOG_DIR}/mailman3-access.log combined

    SSLProxyEngine on
    ProxyPreserveHost on

    <Location />
        Require all granted
    </Location>

    Alias /static/ /opt/mailman/web/static/

    ProxyPass /static/ !
    ProxyPass / http://localhost:8000/

    SSLEngine on
    SSLCertificateFile    /etc/ssl/private/work.hogeserver.hogeddns.jp.crt
    SSLCertificateKeyFile /etc/ssl/private/work.hogeserver.hogeddns.jp.key
</VirtualHost>

80番ポートへのアクセスは443へ書き換える。
証明書はオレオレ認証局が発行したものを使っているが、使えるものなら何でも構わない。

デフォルトページを無効化し、Mailman3のページを有効化する。また、必要なモジュールを有効化する。

$ sudo a2dissite 000-default.conf
$ sudo a2ensite mailman3.conf
$ sudo a2enmod rewrite ssl headers remoteip proxy proxy_http
$ sudo apachectl configtest
Syntax OK

Apacheを再起動して設定を反映させる。

$ sudo systemctl restart apache2

https://work.hogeserver.hogeddns.jp/にアクセスし、文字や画像が問題なく表示されることが確認できればOK。

Postfixの設定

Mailman3とPostfixが連携できるように設定していく。
この段階ではまだ、中身のないファイルを定義に入れているかもしれない。

/etc/postfix/main.cf

…
mynetworks = 172.19.199.0/24 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128
…
transport_maps = hash:/etc/postfix/transport regexp:/opt/mailman/core/var/data/postfix_lmtp

# Mailman
unknown_local_recipient_reject_code = 550
owner_request_special = no
local_recipient_maps = proxy:unix:passwd.byname $alias_maps regexp:/opt/mailman/core/var/data/postfix_lmtp
relay_domains = regexp:/opt/mailman/core/var/data/postfix_domains

mynetworksにはdocker-compose-mysql.ymlに書かれているネットワーク構成を加えて、Mailman3からメール送信ができるようにしておく。

また次の3つの設定で、届いたメールが転送対象になり、宛先として認識され、指定の方法でMailman3に転送される。

  • Mailman3で登録したドメインは、/opt/mailman/core/var/data/postfix_domainsに書き出され、これをrelay_domainsで転送対象にしている。
  • local_recipient_mapsでpostfix_lmtpを指定している。これで当該のメールアドレスが自分宛てであることを示す。
    手前に定義したproxy:unix:passwd.byname $aliasは、Mailman3のインストール説明にない値で、Postfixのデフォルト値。これを設定しておかないと、このホストのアカウントにメールが届かなくなってしまう。
  • tramsport_mapsでもpostfix_lmtpを指定していて、メーリングリスト宛のメールを、LMTPでMailman3に転送するように設定している。
    postfix_lmtpはMailman3が作ってくれて、メーリングリストのメールアドレス＋これにまつわる8つのメールアドレスと、転送先・方法が定義されていた。

Dockerイメージの更新

このテーマに取りかかったのが9月4日、現在10月2日。もたもたと整理していたら、イメージが0.3から0.4にバージョンアップしていた。
docker-compose-mysql.yaml の変更履歴を確認したところ、今回の変更はバージョン指定だけだったようなので、そこだけを書き換えて更新してみた。

コンテナを停止して、イメージ、コンテナを削除。

$ sudo docker-compose -f docker-compose-mysql.yaml down

今回の変更点を反映、具体的にはバージョンを書き換えた。
docker-compose-mysql.yaml

version: '2'

services:
  mailman-core:
    image: maxking/mailman-core:0.4
…
  mailman-web:
    image: maxking/mailman-web:0.4
…

起動する。

$ sudo docker-compose -f docker-compose-mysql.yaml up -d

これで、起動時に新しいイメージをダウンロードしてきてくれた。
データーもちゃんと永続化されており、問題なく処理を再開できた。

Mailman3でメーリングリストを作成

ここまでの操作でMailman3が動作する環境が整ったので、Mailman3でメーリングリストを作っていく。

管理者ユーザーでサインイン

サイトオーナーのメールアドレスrohhie@rohhie.netをdocker-compose-mysql.ymlで設定したが、パスワードが設定されていない。

画面にある「サインイン」リンクをクリックし、「パスワードを忘れましたか？」のリンクをクリックする。
メールアドレスを入力し、「パスワードをリセットする」のボタンをクリックして、届いたメールに沿って作業を進めていく。

サイトオーナーのパスワードが更新されたら、改めてサインインする。
※このシステムはログインとサインインの言葉が混在している。翻訳だけの問題かもしれない。将来的には統一されるのだろう。

このパスワード設定は、ApacheやPostfixがちゃんと設定できているのかどうかを確認するプロセスなのかもしれない。

ドメインを追加

立てたホストとは違う2つのドメインのメーリングリストを運営するため、これらをドメインを登録した。

設定項目rohhie.netmyhome.local
メールホストrohhie.netmyhome.local
説明技術メモ家庭用
エイリアスドメイン[空][空]
ウェブホストwork.hogeserver.hogeddns.jpwork.hogeserver.hogeddns.jp

エイリアスドメインは例えば ml-theme@rohhie.net というメーリングリストだけれども、配送の都合上 ml-theme@work.hogeserver.hogeddns.jp としてMailman3に送りたい、といった場合に設定する。転送については後編で記載する。

メーリングリストを追加

管理者のrohhie@rohhie.netでログインし、それぞれのドメインにメーリングリストを登録する。

設定項目rohhie.net
(メールだけでなくWebも利用する想定)		myhome.local
(業務用のメーリングリストを想定)		備考
リストの名前ml-thememl-info
メールホストrohhie.netmyhome.local
最初のリストオーナーのアドレスrohhie@rohhie.netrohhie@rohhie.netサーバーのオーナーを設定。
Advertise this list?Advertise this list in list indexHide this list in list index
List StyleOrdinaly discussion mailing list style.Announce only mailing list style.型を決めるイメージ。
説明技術テーマについて語ろう！家族のお知らせ

業務用のメーリングリストを想定し、オーナーをサーバーのオーナーに設定してみた。
ユーザー側に管理させずに、メーリングリストの設定、メンバーの追加削除をすべて管理者がやるって感じで。
こんな管理をしているケースも結構あるんじゃないかなと。

メーリングリストの最低限の設定

この後で、管理サーバーからのメッセージテンプレートに(例えばドメイン単位で)日本語を設定したりすると、ようこそメールが文字化けしてしまう。

細かな設定はこの先で幾つか記載するが、まずこれだけはやっておく。
これには「リスト設定」→「List Identity」のページにある推奨言語で「Japanese」を選択する。

メンバーの管理

管理者、または、メーリングリストのオーナーとしてログインすると、メンバーの管理ができる。
Mass operationsからのMass subscribe(一括購読)、Mass removal(一括解除)ができる。

設定項目ml-theme@rohhie.net
(メールだけでなくWebも利用する想定)		ml-info@myhome.local
(業務用のメーリングリストを想定)		備考
Emails to mass subscriberohhie@rohhie.net
"ドメイン管理者" <kanri@rohhie.net>
"ほげほげ管理者" <kanri@myhome.local>		hoge@myhome.local
"ドメイン管理者" <kanri@myhome.local>		色々な書き方でメンバーを追加できる。
1行1人。
Pre confirmチェックなしチェックユーザーが購読を決めた状態にする。
Pre approvedチェックなしチェックモデレーターの承認済み状態にする。
Pre Verifiedチェックなしチェックユーザーのメールアドレスを確認済み状態にする。
Invitationチェックなしチェックなし招待メールを送る(他のチェックは無視)
Send welcome messageList defaultいいえ
結果登録した人に招待メールが送られる。連絡なしでメーリングリストに追加される。

メーリングリストに登録されたメンバーのアカウントが作られるのかと思いきや…そんなことはなかった。

Mailman3のアカウント作成

メーリングリストに登録されたからといってMailman3のアカウントができるわけではなかった。
購読者になっても、オーナーになっても、それだけではアカウントができたりはしない。
※オーナーのアカウントがなくてもメーリングリストは運用可能。

メーリングリストの管理をオーナとなる人に任せるのならば、オーナーにはアカウントを作ってもらう。
Mailman3のサイトにアクセスし「登録」リンクをクリックすることで、アカウントを自由に作成できるので、そうしてもらう。

登録済みのメールアドレスを入力し、送られてきた確認メールに対してアクションすればOK。
後からアカウントができても、メールアドレスが一致すれば同一人物と認識される。
具体的には、kanri@myhome.localをオーナーとするメーリングリストを作り、後からアカウントを作ってみたところ、管理者として振る舞うことができた。

コマンド操作

Mailman3で何かをしようと思ったとき、Web UIで操作するのが簡単だが、コマンドでの操作もできるようになっている。

マニュアルに書かれたコマンドを実行する場合には、Mailman Shellを起動する。
Gnu Mailman / Installing and running Mailman 3

$ sudo docker exec -u 0 -it mailman-core /bin/bash --login
mailman-core:/opt/mailman# mailman --run-as-root shell
>>> [ここからコマンド入力が可能]

※Dockerイメージが0.4になったから？か、--run-as-rootを付けて起動するようになった。

Pythonが起動して必要なライブラリ等が読み込まれた状態になる。

SPFの考慮

メーリングリストに投稿されたメールは、Mailman3からメンバーに展開される。
その際のヘッダーを一部抜粋する。

Return-Path: <ml-info-bounces@myhome.local>
Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=192.168.0.3;
 helo=work.hogeserver.hogeddns.jp;
 envelope-from=ml-info-bounces@myhome.local; receiver=<UNKNOWN>
From: "ドメイン管理者" <kanri@myhome.local>

SPF判定のところを見ると、envelope-fromはメーリングリストのドメイン、そのメールを渡してきたのはwork.hogeserver.hogeddns.jp(192.168.0.3)と捉えて、判定が行われている。

このことから、メーリングリストを運用するにあたっては、

  • Mailman3からメールを送信する場合は、登録済みのメールサーバー(この場合は、myhome.local)を通してもらう
  • Mailman3が稼働するサーバーをSPFレコードに入れてメンバー直送してもらう

といった対策をしておく必要がある。

マルチドメインの場合、envelope-fromによってでリレー先のサーバーを変えたくなることもあるかもしれない。
技術メモの壁 / Postfixで送信者(From:)によってルーティングを変更する

DKIMの署名の取り扱い

DKIMの署名がなされたメールがMailman3に届く → そのヘッダーも含めた形でメーリングリストのメンバーにメッセージが飛ぶ → 受信時に最初の署名を再判定して失敗判定になる。

Authentication-Results: rohhie.net;
	dkim=pass (1024-bit key; unprotected) header.d=myhome.local header.i=@myhome.local header.b="LUpxNkT9";
	dkim=fail reason="signature verification failed" (1024-bit key) header.d=myhome.local.i=@myhome.local header.b="xao9NXtM";
	dkim-atps=neutral

それでも、この情報に意味があると考えるケースもあるかもしれない(最初にメールを出した人が本当にその人なのか？とか)。
あるかもしれないけど、やっぱりちょっと気になったので古い署名を削除する方法を探してみた。
Gnu Mailman / Configuring Mailman

このDockerイメージはとても作りが良くて、一生懸命中に入り込んで云々しなくても、このファイルに入れた設定をMailman3のconfigファイルに追記してくれる。
また、Mailman3も例えばセクション[mta]が何回現れても問題ないように作られていることが分かった。なので…

/opt/mailman/core/mailman-extra.cfg ※なければ新規に作成

[mta]
remove_dkim_headers: yes

これを追加して、コンテナを再起動すれば、設定が反映される。

$ sudo docker restart mailman-core

結果として、古い署名が消されて、このような判定結果となった。
また、SPF判定はそのまま残されているので、まぁ良し。

Delivered-To: rohhie@rohhie.net
Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=192.168.0.nnn; helo=myhome.local; envelope-from=ml-theme-bounces@rohhie.net; receiver=<UNKNOWN> 
Authentication-Results: rohhie.net; dmarc=none (p=none dis=none) header.from=myhome.local
Authentication-Results: rohhie.net;
	dkim=pass (1024-bit key; unprotected) header.d=myhome.local header.i=@myhome.local header.b="FUh7xCK7";
	dkim-atps=neutral
…
Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=192.168.0.nnn; helo=myhome.local; envelope-from=hoge@myhome.local; receiver=<UNKNOWN>

だいぶ思い通りに動くようになってきた。

業務用の設定

メールのやりとりだけができるメーリングリスト、それ以外の機能は使わない・使わせない。
といった運用も全然普通にあると思っていて、そんなテンプレートが作りたいくらいだなぁ、と思った。

設定画面をみながら、ユーザーマニュアルをみて設定してみている。
以降、言い切りで書いているところは実験済み。それ以外は推定で書いている。

リクエストメールを受け付けない

メーリングリストへの参加、オプション設定の変更、離脱がメール一本でできるのだが、これができないようにする。

「リスト設定」→「Automatic Responses」のページにあるAutorespond requestsで「Respond and discard message」を選択する。
ホントは「No automatic response」が正しいと思うのだが、表示だけの問題？なのか、この設定で応答しなくなる。

アーカイブしない

後からメーリングリストに入った人はもちろん、メーリングリストに入っていない人にも情報を共有できる。
それがメーリングリストの良さだし、実際、かなり見やすくて使いやすい画面が用意されている。

しかし、業務で利用するときには、そうした機能を求められていない場合もあって、アーカイブしているのは容量の無駄になる。

これには「リスト設定」→「Archiving」のページにあるArchive Policyで「Do not archive this list」を選択する。

もし、アーカイブができはじめていたら、管理者でログインした上で、アーカイブを表示する画面に飛んで「削除」ボタンを押せば、アーカイブを削除することができる。

ダイジェストを送らない

デフォルトでは1月に1回ダイジェストが送られてくるようだ。
コミュニティで利用する場合、アクセスを忘れているユーザーに動きが伝わる良い機能。

しかし、業務で利用するときには、恐らくは必要がない。

これは「リスト設定」→「Digest」のページにあるEnable Digestsで「いいえ」を選択すれば良さそうだ。

返信先をメーリングリストにする

世の中的には、メーリングリストの返信先はそのメールを出した個人になるのが普通。
しかし、業務で利用するときには、返信を共有するためにメーリングリストを宛先にしたい場合も多い。

これには「リスト設定」→「Alter Messages」のページにあるReply goes to listで「Reply goes to list」を選択すれば良い。

List-*ヘッダーを付けない

情報交換のためのメーリングリストならば、これらのヘッダーは必要。

List-Id:  家族のお知らせ <ml-info.myhome.local>
Archived-At: <https://work.hogeserver.hogeddns.jp/hyperkitty/list/ml-info@myhome.local/message/L7PBQJKPOKVGKOGUKY5KDQBQIFJ6I4FB/>
List-Archive: <https://work.hogeserver.hogeddns.jp/hyperkitty/list/ml-info@myhome.local/>
List-Help: <mailto:ml-info-request@myhome.local?subject=help>
List-Owner: <mailto:ml-info-owner@myhome.local>
List-Post: NO
List-Subscribe: <mailto:ml-info-join@myhome.local>
List-Unsubscribe: <mailto:ml-info-leave@myhome.local>

メールヘッダーなのでメーラーによって隠されて全く見られないかもしれないが、業務で使用するときにこのヘッダーはないほうが良さそう。

これには「リスト設定」→「Alter Messages」のページにあるInclude RFC2369 headersで「いいえ」を選択する。

メンバー以外の投稿を許可

業務の場合だと普通にありそうな、代表メールアドレスに出してもらうと、関係する全員にメールが届くような運用。
デフォルトでは、オーナーが投稿を許可しないとメールが配信されない。

これには「リスト設定」→「Message Acceptance」のページにあるDefault action to take when a non-member posts to the listで「即座に承認(他のルールを無視)」を選択する。

件名に番号を振る

メーリングリストの番号が重宝されるような業務もあるかもしれない。
デフォルトでは件名の先頭に[ml-theme]が付くのみで、番号は表示されない。

これには「リスト設定」→「List Identity」のページにあるSubject prefixに %05d 等の書式を入れておく。

無効なアドレスの取り扱い

何らかの理由でメールアドレスがなくなっていたり、相手サーバーが受信を拒否する場合がある。
これが何度も続くと、メーリングリストはそのメールアドレスを無効にして、オーナーにそのことを伝えてくれる。

この動きそのものを止めたい場合は「リスト設定」→「Bounce Processing」でProcess Bouncesを「いいえ」にしておけば良さそう。
無効にするけれどもオーナーに伝えない場合は、Notify owner on removalを「いいえ」にしておけば良さそう。

メールを送信すると、自動的にフッターが付与される。

…
_______________________________________________
Ml-info mailing list -- ml-info@myhome.local
To unsubscribe send an email to ml-info-leave@myhome.local
(最後に改行もされている)

これをメーリングリストに返信すると、さらにフッターが追加される。

業務で使用する場合には、こうしたフッターは付けずに運用されていることが多いのではないだろうか。
lists.mailman3.org / Removing the footer from mails

これは、恐らくはドメイン単位の指定になると思われるので、 「ドメイン」→当該ドメインの「テンプレート」→「新しいテンプレート」と進み、「Name」で[list:member:regular:footer]を選択し、空の状態のまま保存する。

これでフッターが付与されなくなる…が、改行が1つだけ付与される。

設定をスクリプトで登録

作り込んだ設定をスクリプトで流し込めるといいな、と。
1つ2つなら手作業で設定しても良いのだけれども、10だの20だのとなったら大変だろうなと。
Mailing list configuration

List Styleとして「Announce only mailing list style.」を選択して作ったメーリングリストに、上記の設定を入れた結果を見てみる。
※localhostではアクセスできないので、IPアドレス(172.19.199.3)を指定している。
※コマンドを打ち込んでみれば分かる話だったりもするので、関係するのは恐らくココ、というところを抜粋。

$ sudo docker exec -u 0 -it mailman-core /bin/bash --login
mailman-core:/opt/mailman# mailman --run-as-root shell
>>> from mailman.testing.documentation import dump_json
>>> dump_json('http://172.19.199.3:8001/3.0/lists/ml-info@myhome.local/config')
accept_these_nonmembers: []
acceptable_aliases: []
admin_immed_notify: True
…
archive_policy: never
autorespond_requests: respond_and_discard
default_nonmember_action: accept
digests_enabled: False
include_rfc2369_headers: False
process_bounces: False
reply_goes_to_list: point_to_list
subject_prefix: [Ml-info %05d]
…
usenet_watermark: None
volume: 1
welcome_message_uri:
>>>

マニュアルによれば、設定値を全部書くか、1つだけ書き換えるかのどちらかができるとのこと。
Excelかなんかで、全設定値のリストを作って、何カ所か計算式で編集できるようにして、コマンドをペタッと貼る…とかいう計画を立てるのが良さそうな気もするが、ここでは1つずつパッチを当てる式を書いてみる。

$ sudo docker exec -u 0 -it mailman-core /bin/bash --login
mailman-core:/opt/mailman# mailman --run-as-root shell
>>> from mailman.testing.documentation import dump_json
>>> dump_json('http://172.19.199.3:8001/3.0/lists/ml-info@myhome.local/config',dict(archive_policy='never'),'PATCH')
>>> dump_json('http://172.19.199.3:8001/3.0/lists/ml-info@myhome.local/config',dict(autorespond_requests='respond_and_discard'),'PATCH')
>>> dump_json('http://172.19.199.3:8001/3.0/lists/ml-info@myhome.local/config',dict(default_nonmember_action='accept'),'PATCH')
>>> dump_json('http://172.19.199.3:8001/3.0/lists/ml-info@myhome.local/config',dict(digests_enabled='False'),'PATCH')
>>> dump_json('http://172.19.199.3:8001/3.0/lists/ml-info@myhome.local/config',dict(include_rfc2369_headers='False'),'PATCH')
>>> dump_json('http://172.19.199.3:8001/3.0/lists/ml-info@myhome.local/config',dict(process_bounces='False'),'PATCH')
>>> dump_json('http://172.19.199.3:8001/3.0/lists/ml-info@myhome.local/config',dict(reply_goes_to_list='point_to_list'),'PATCH')
>>> dump_json('http://172.19.199.3:8001/3.0/lists/ml-info@myhome.local/config',dict(subject_prefix='[Ml-info %05d]'),'PATCH')

これで説明したウチの8項目がアップデートできる。

List Style登録(失敗)

何か1つのMLでしっかりと設定しておけば、それがテンプレート的に使えるのか？も？？ということでList Styleの登録を試してみたけれども、マニュアルにあるコマンドをほぼそのまま叩いた結果、使用できないメーリングリストが1つできあがっただけだった…。

$ sudo docker exec -u 0 -it mailman-core /bin/bash --login
mailman-core:/opt/mailman# mailman --run-as-root shell
>>> from zope.component import getUtility
>>> from mailman.interfaces.styles import IStyleManager
>>> manager = getUtility(IStyleManager)
>>> from zope.interface import implementer
>>> from mailman.interfaces.styles import IStyle
>>> @implementer(IStyle)
... class BizStyle:
...     name = 'biz-style'
...     description = 'Style for business use.'
...     def apply(self, mailing_list):
...         mailing_list.display_name = 'BUSINESS STYLE'
...
>>> manager.register(BizStyle())

>>> for style in manager.styles:
...     print(style.name)
...
biz-style
legacy-announce
legacy-default
private-default

>>> biz_style = manager.get('biz-style')
>>> from mailman.app.lifecycle import create_list
>>> mlist = create_list('biz@rohhie.net', style_name=biz_style.name)

後から…
>>> dump_json('http://172.19.199.3:8001/3.0/lists/biz@rohhie.net/config')
Traceback (most recent call last):
  File "<console>", line 1, in <module>
  File "/usr/lib/python3.8/site-packages/mailman/testing/documentation.py", line 138, in dump_json
    results = call_http(url, data, method, username, password)
  File "/usr/lib/python3.8/site-packages/mailman/testing/documentation.py", line 96, in call_http
    content, response = call_api(url, data, method, username, password)
  File "/usr/lib/python3.8/site-packages/mailman/testing/helpers.py", line 328, in call_api
    raise HTTPError(
urllib.error.HTTPError: HTTP Error 500: None

mailman-core再起動後…
>>> from zope.component import getUtility
>>> from mailman.interfaces.styles import IStyleManager
>>> manager = getUtility(IStyleManager)
>>> for style in manager.styles:
...     print(style.name)
...
legacy-announce
legacy-default
private-default

mailman-coreを再起動したところ、登録したはずのbiz-styleが消えてしまい、今の時点でこれは使えそうもないと思った。

後編へ続く。

広告
rohhie

コメントはこちらから お気軽にどうぞ ～ 投稿に関するご意見・感想・他

  1. Hisashi MINAMINO より:
    2024年9月11日 10:32

    styleはdbのtableに格納されるのではなく、mailman coreのコードの上の存在であるようです。
    このため、mailman自身を書き換える(書き足す)か、pluginを用意してそこで定義して適用させることになると考えます。私は後者でうまくゆきました。
    pluginのサンプルは、こちら。
    https://gitlab.com/mailman/example-mailman-plugin

    なお、StyleManagerのregisterは、うまく機能しません。この理由の根本には至れませんでしたが、populateであれば追加することが出来ました。
    pluginの初期化用クラスの、post_hookでコードを書き足しました。

    また、特定のstyleをデフォルトに指定したい場合は、styleの名前(name属性値)を mailman.cfg に記載することで可能です。

    返信
    • rohhie より:
      2024年9月14日 12:30

      投稿の確認が遅れまして恐縮です。
      これ、職場で使うかもしれないと思って調べて書いた記事なんですが、結局採用されませんでした(笑)
      上手く使えば記録も残るし、良いものですよねメーリングリストって。
      情報提供いただきまして、ありがとうございました。

      返信