(ヽ'ω`) < Mailmanを"まずは動くまで"設定
(ヽ´ω`) < インストールの続き
前回までで、Mailmanを使うためのファイルの配置と、Postfix, Apacheの連携ソフトウェアの設定を行った。
かなり長い手順となったが、今回はMailman自身の設定を行っていく。
- Mailmanの初期設定
- mm_cfg.pyの設定
- aliasesファイルの仮作成
- 管理ML(mailman)作成
- マスターパスワード設定
- 動作を確認
- 投稿確認
- Gmailからの投稿確認
(ヽ´ω`) < Mailmanの初期設定
以下の手順を行い、Mailmanが正常に起動するまでもっていく。ここでは、個別のカスタマイズについては触れない。設定項目があまりにも多いため、別のエントリで逆引き形式で解説を行う。
mm_cfg.pyの設定
Mailmanでは、あらゆるシステムのデフォルト設定値がMailman/Defaults.py
というファイルに記載されている。
このファイル自身は、拡張子を見て分かる通りpythonスクリプトそのものとなっているが、ApacheやPostfixの設定ファイルと同じように
変数名 = 値
の形式で設定を入れているだけなので、読んでいく分にはあまり問題がないと思う。
各変数名(設定項目)がどういう働きをするのかも、このファイルに記載されているので、このファイルを参照すればどのような設定が行えるかがわかるようになっている。
で、システムの設定をデフォルトから変更したい時、
例えば、デフォルトではMailmanから配送されたメールの返信先は、送信者のアドレスとなっているが、これをメーリングリストのアドレスに変更したい、という場合
Defaults.py
のDEFAULT_REPLY_GOES_TO_LIST
の値を0
から1
に変更する、のではなく
同じディレクトリ(Mailman/
)のmm_cfg.py
というファイルに、設定を記述する。
# Mailman/Defaults.pyの以下の記述はそのままで DEFAULT_REPLY_GOES_TO_LIST = 0 # Mailman/mm_cfg.pyに以下の記述を追加する DEFAULT_REPLY_GOES_TO_LIST = 1
これはシステムの正常性を保つのに非常に便利な話で、Defaults.py
に記載されているデフォルト値は変更されないので、不都合が発生して、その原因が不明な場合はmm_cfg.py
の内容を削除してしまえば、元の状態に戻すことができる。
本来であれば、ここでメーリングリストの基本的な設定を記述してくことになるのだが、まずは最低限の記載のみを行う。
# 1) 連携するMTAの名前を指定 MTA = 'Postfix' # 2) WebUIからアクセスする際のFQDN DEFAULT_URL_HOST = 'mailman-ui.tsugihagi.net' # 3) メーリングリストアドレスの@以降の部分 DEFAULT_EMAIL_HOST = 'ml.tsugihagi.net' # 4) 上記のDEFAULT_*_HOSTを変更した場合、 # 下記の通りadd_virtualhostメソッドを呼び出す add_virtualhost(DEFAULT_URL_HOST, DEFAULT_EMAIL_HOST)
各項目についての説明
- 連携するMTAの名前を指定
ここではPostfixを使用するので、値にはPostfix
を指定。他にはMailman/MTA/
ディレクトリ以下のクラスの名前が使用可能とのことだが…Manual
とPostfix
しか無い。完全にPostfixとの連携が前提なんですかね。 - WebUIからアクセスする際のFQDN
Mailmanが提供するWebUIのURL内の、ホスト名部分を指定する。ここでは
http://mailman-ui.tsugihagi.net/mailman/
というURLで提供することを想定。URL内の斜体の部分が対象の値となる。 - メーリングリストアドレスの@以降の部分
各メーリングリストのアドレスが
hogehoge@ml.tsugihagi.net
となるとして、斜体の部分。もしも foobar@tsugihagi.net
とした場合はDEFAULT_EMAIL_HOST = 'tsugihagi.net'
となる。 - add_virtualhostの呼び出し
DEFAULT_URL_HOSTとDEFAULT_EMAIL_HOSTの値を変更した時には、必ずこのメソッドを呼び出す必要がある。ここはMailmanをバーチャルホストで運用した場合の話もからんでくるのだが、とりあえずおまじない的に覚えておく。
mm_cfg.py
について補足しておくと、このファイルの内容がそのまま、各メーリングリストの設定として扱われるわけではない。
このファイルの内容を読み取って、各メーリングリストの設定内容がconfig/<メーリングリスト名/config.pck
というファイルに書き出される。
この辺りの細かい話は、メーリングリストのカスタマイズに関連して、別エントリで解説を行う。
aliasesファイルの仮作成
下記のコマンドでaliasesファイルを作成する。このファイルはメーリングリストの作成・削除を行う度に更新されるので、ここでは問題なく作成できるかをだけを確認する。
# /opt/mailman/bin/genaliases
上記コマンド実行後に、data/
以下にaliases
, aliases.db
と2つのファイルが作成されている事を確認しておく。
[root@d09f4ab28203 data]# ls -l total 36 -rw-rw---- 1 root mailman 351 Dec 15 06:07 aliases -rw-r----- 1 root mailman 12288 Dec 15 06:07 aliases.db -rw-r--r-- 1 root mailman 10 Dec 15 05:51 last_mailman_version -rw-r--r-- 1 root mailman 14100 Dec 15 05:51 sitelist.cfg [root@d09f4ab28203 data]# cat aliases # This file is generated by Mailman, and is kept in sync with the # binary hash file aliases.db. YOU SHOULD NOT MANUALLY EDIT THIS FILE # unless you know what you're doing, and can keep the two files properly # in sync. If you screw it up, you're on your own. # The ultimate loop stopper address mailman-loop: /opt/mailman/data/owner-bounces.mbox
管理ML(mailman)作成
Mailmanではシステムの管理のために、1つのメーリングリスト('site-wide mailing list')が必要となる。
パスワードリマインダー等は、このメーリングリストのアドレスから届くことになる。他にも色々なところで使われる…っぽいのだが、あんまり見たことがない。
このメーリングリストはデフォルトではmailman
という名前となる。(もしもこの名前が気に喰わない場合は、mm_cfg.py
でMAILMAN_SITE_LIST
という名前の変数を設定することで変更が可能)
メーリングリストの作成は、bin/newlist
コマンドを使用する。このコマンドの引数は以下の通り。
newlist <メーリングリスト名> <管理者のメールアドレス> <管理パスワード>
ここではmailman
という名前のメーリングリストを作成するので、
# /opt/mailman/bin/newlist mailman ml-admin@tsugihagi.net sOme_PA$$W0RD
上記コマンドで、mailman@ml.tsugihagi.net
というメーリングリストが作成された。
コマンド実行時に、エンターを押すと管理者にメールを送信した旨のメッセージが表示されるが、実際にはMailmanのサービスはまだ実行されていないので、送信は行われない。
実際にmailmanというメーリングリストが作成されたことを、システム上で確認してみる。
まずは、lists/
ディレクトリにmailmanというディレクトリが存在しているか。
[root@d09f4ab28203 mailman]# pwd /opt/mailman [root@d09f4ab28203 mailman]# cd lists [root@d09f4ab28203 lists]# ls -l total 4 drwxrwsr-x 2 root mailman 4096 Dec 15 06:11 mailman
次に先ほどgenaliases
で作成されたdata/aliases
ファイルにエントリが追加されているか。
[root@d09f4ab28203 lists]# cat /opt/mailman/data/aliases # This file is generated by Mailman, and is kept in sync with the # binary hash file aliases.db. YOU SHOULD NOT MANUALLY EDIT THIS FILE # unless you know what you're doing, and can keep the two files properly # in sync. If you screw it up, you're on your own. # The ultimate loop stopper address mailman-loop: /opt/mailman/data/owner-bounces.mbox # STANZA START: mailman # CREATED: Mon Dec 15 06:10:11 2014 mailman: "|/opt/mailman/mail/mailman post mailman" mailman-admin: "|/opt/mailman/mail/mailman admin mailman" mailman-bounces: "|/opt/mailman/mail/mailman bounces mailman" mailman-confirm: "|/opt/mailman/mail/mailman confirm mailman" mailman-join: "|/opt/mailman/mail/mailman join mailman" mailman-leave: "|/opt/mailman/mail/mailman leave mailman" mailman-owner: "|/opt/mailman/mail/mailman owner mailman" mailman-request: "|/opt/mailman/mail/mailman request mailman" mailman-subscribe: "|/opt/mailman/mail/mailman subscribe mailman" mailman-unsubscribe: "|/opt/mailman/mail/mailman unsubscribe mailman" # STANZA END: mailman
この2点で正常にメーリングリストが作成されたどうかを判別できる。(実際に問題なく配送されるかは別だが)
マスターパスワード設定
マスターパスワードという名前は勝手につけた名前で、公式ドキュメントでは'site password'と表記されている。
このパスワードはMailmanに関する全ての操作を行うためのパスワードで、Linuxシステムでのrootパスワードと、ほぼ同じとなる。
以下のコマンドで作成する。
# mmsitepass <パスワード> # /opt/mailman/bin/mmsitepass My-$lt3-p@$sW0rD
当然、取り扱いには最大限の注意を
(ヽ´ω`) < 動作を確認
これでようやく設定は完了。実際にMailmanの動作を確認する。
と、その前にMailmanのサービスが起動していないので起動してやる。
CentOS6で使用できるSysVinit用のサービス起動スクリプトが、script/mailman
にあるので、それを/etc/init.d/
にコピーして起動する。
# cp /opt/mailman/script/mailman /etc/init.d/ # chkconfig --add mailman # service mailman start
投稿確認
早速投稿確認を行う。
現在の状態で、システムにはmailman@ml.tsugihagi.net
というメーリングリストが1つだけ存在するので、そこにユーザを追加して、投稿が配送されるかを確認する。
今回はサーバ側の解説がメインなので、この辺りの操作は、実際の運用で作成された手順書等を参考にしてもらいたい。「Mailman 運用」でググると山ほど手順書が引っかかる。
Gmailからの投稿確認
Gmailでは同一のMessage-IDを持つメールを重複メールとして扱う、という仕様がある。
Message-IDはメールの送信時に決定されるが、GmailからMailmanに投稿を行った場合、送信は問題なく行われるが、"自分宛に配信されたメール"と"自分が送ったメール"は同一のMessage-IDを持つ。
そのため、Mailmanから送信されたメッセージは、Gmailの受信トレイをスキップして、そのままアーカイブされる(自分が送ったメールが自分へと配信されていないように見える現象が起こる)
これはMailmanに限った話ではなく、送信元のMessage-IDを保持するポリシーのメーリングリストシステム全般に起こりうる問題となる。
MailmanのMLではMessage-IDを書き換えるか否かについて、散々に議論された結果、書き換えを行わないという方針となっている。将来的に方針が変更される可能性があるかもしれないが、少なくとも現状ではシステム側・あるいは運用面で対応する必要がある。
運用で対応する場合は「Gmailからの投稿については、送信者へ配送されません」とアナウンスを行えば良いだけなのだが…、新規ではなくリプレース(Majordomoなど)の場合、混乱が起こる可能性がある。
オリジナルのソースに手を加えるリスクを取るか、運用面での手間を取るかはケースバイケースだが、今回の解説では上記の問題に対応した+jバージョンをtarballからインストールすることで、システム側での対応を行った。
実際にGmailアカウントから投稿を行うと、自分が送信したメッセージがちゃんと受信トレイに表示されると思う。
(ヽ´ω`) < ここまでが初期設定
以上でMailmanのインストール部分については完了。
このままの状態で使い続けられるような環境ならば良いんだけど、殆どの場合はそうじゃないはず。
先ほど例でも上げたとおり
- 投稿の返信先を送信者ではなく、メーリングリストにしたい
- 返信時の「Re:」の付く場所を変更したい
- Subjectに自動的に付与される文字列を変更したい
- WebUIがあるからメールコマンドを無効化したい
など、いろいろな要望があるかと予想されるので、カスタマイズの方法や、運用面でのトラブルシュート、ログの見かたなどを書いていく予定。
(ヽ´ω`) < インストール手順のページは山ほどあるから、どちらかというと、そっちのほうがメインコンテンツですかね。