Mailman-設定

設定

基本的には、画面に説明があり、その通り動作する。
一部、UI上の記載が不十分だったり、メール運用の知見が必要な点もあるので、設定の推奨項目と、内容について補足を記載する。

ただ、個別の設定について詳細な動作の検証はしていない。
詳細な内容や、より正確な内容が必要な場合、各自公式マニュアルを確認したり、検証を行うこと。

また、設定によってはサーバ全体に対して致命的な影響をあたえうる。
推奨項目以外の設定を行う際は、あらかじめ十分な理解の上行うこと。

なお、設定の変更後、画面下部の「変更を保存する」ボタンを押さないと反映されないので注意すること。

以下、各項目について推奨設定を示し、一部説明を補記する。

リスト識別設定

「一覧ページにリストを表示」を「いいえ」にする（必須）
これはメーリングリストの非表示設定で、「はい」の状態だとmailmanのページにアクセスするだけで、存在するアドレスとして確認できてしまう。
システムの仕様上、MLの作成時のデフォルトが「はい」となっているので、注意すること。
「簡易説明」（任意）
説明にある通り、任意のものを設定すると良い。
「詳細説明」（任意）
説明にある通り、任意のものを設定すると良い。
「表示名」は「デフォルトのもの」(推奨)
変えてもいいが、単に見づらくなる。どうしてもやるなら管理上有益なものとして客観的に妥当なものにすること。
「件名プレフィックス」は「デフォルトのもの」 (任意)
このMLの配信時、メールの件名の頭についている文字を指定できる。
これについてはMLの利用目的と管理者の方針次第で消したり変更してよい。
「優先言語」「Japanese」 (推奨)
変更したい場合してよい。
ただし統合サーバ担当においてはJapaneseで各動作を確認していることを留意されたい。
「メンバーリストの可視性」を「メーリングリストの管理者のみ」にする (必須)
当然だが、アドレス一覧を確認できるのは管理者だけでいい。メンバ間での閲覧も不要のはずなので、可能な限り個人情報が閲覧できない設定を行うこと。

自動応答設定

本項目で行うべき設定はMLの利用目的や、管理者の方針にもよるが、スパムメールに自動応答を行わないような設定を推奨としている。
また、スパム以外でもMLの自動応答を利用者が受けとって嬉しいという事例はあまりなさそうである。
おそらくは管理者のみが通知を受け取ることができれば十分だろうと考えている。

「オーナーからの自動応答」は「自動応答なし」 (推奨)
「オーナーから自動応答する文章」は自動応答なしのため不要
「投稿時の自動応答」は「自動応答なし」 (推奨)
「投稿者へ自動応答する文章」は自動応答なしのため不要
「申請時の自動応答」は「自動応答なし」 (推奨)
「申請者へ自動応答する文章」は自動応答なしのため不要
「自動応答の猶予期間」は「90d」(推奨)
実際にはmailmanのデフォルトが90dのためそれを推奨としているのみで、推奨では自動応答を行わない設定にしているため、特に意味はないはず。
「保留メッセージをユーザーに通知」は「いいえ」(推奨)
「歓迎メッセージを送信」は「いいえ」(推奨)
「お別れのメッセージを送る」は「いいえ」(推奨)
「すぐに管理者に通知」は「はい」(推奨)
「メンバー変更の管理者への通知」は「いいえ」(推奨)

メッセージの変更

本項目については、統合サーバ担当でも完全には理解していない点が多い。
各ML管理者においても設定の内容や影響範囲がわからない場合、推奨値以外に変えるべきでないだろう。

「パーソナライズ」は「なし」(推奨)
どのような設定か不明であり検証していない。
おそらくは、一部のテンプレートで、ユーザデータを参照する変数を使えるようにするものと思われる。
https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/rest/docs/templates.html#templated-texts 特段有益性は感じておらず、検証の予定はない。
「匿名リスト」を「いいえ」（推奨）
メンバへの配信時に送信元をMLに変更し、元の送信元情報を秘匿するようだ。詳細は検証していない。
どのように使うと有益か不明。
おそらくは「List-Post: のヘッダーを含める」をいいえ、「明示的なreply-toアドレス」として該当MLに対する管理者アドレスのようなMLなどを設定して、通知用アドレスのように運用ができる？
このようにする場合、すべてのメールを保留にして運用するのが良いだろうと思う。
特定の目的で良いプラクティスとなる可能性があるが、そのためにどのような設定が必要かMLの設定を理解する必要がある。
「RFC2369ヘッダを含める」は「はい」（必須）
説明にある通り、「いいえ」にする理由はない。
「List-Post: のヘッダーを含める」は「はい」（任意）
RFC 2369に定義されるメーリングリストの投稿先を指定するためのヘッダーらしい。
「はい」とすると、メールクライアントで「リストに返信」のような選択肢が追加されるらしい。
MLを中心とした議論・会話のようなものが目的なら「はい」
メンバーへの一方的な通知・アナウンスを目的とするなら「いいえ」としてもよいらしい。
「返信」「全員に返信」のような選択に対して、デフォルトが「リストへの返信」になるのが望ましくない場合、変更してもよい。
各利用者のメールクライアント等の仕様については保証できないため、その点留意が必要。
「明示的なreply-toアドレス」は基本は「何も書かない」（推奨）
「返信先」をメールクライアントに指示するための「reply-to」というヘッダーが追加される。
これにより、メールクライアントの機能で配信メールに返信を行う場合、このアドレスがtoに指定される。
この内容を含む、現代のメールシステムの前提を理解したうえで、妥当な運用を行えるのであれば任意に設定してよい。
ただし、推奨を「何も書かない」としている通り、MLからのメールに対して特定の返信先を指定するような要望はあまり多くないだろうと思われる。
「投稿の Reply-To: を除去」は「いいえ」（推奨）
元アドレスの「Reply-To」のみを削る運用がどんな時に役立つのかわからない。
もしかすると良い運用方法があるのかもしれない。
1つ上の設定で行うような、所定の返信先をMLに対して常に設定しておきたい場合に使うのかもしれない。
「メーリングリストへの返信設定」は、「返信設定を変更しない」(推奨)
おそらくは「明示的なreply-toアドレス」の設定について有効化するためのもの。
上記の通り、現時点では有効な利用法を特定できていない。
「パイプライン」は「default-posting-pipeline」を設定する(必須)
デフォルトでこの値なので変更しない。パイプラインというのは、配信メールについて、行う処理を定めたセットのようなものらしい。
https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/app/docs/pipelines.html
ドキュメントでも設定ごとの詳細はつかめなかったが、通常配信を期待する場合設定はこれでいいようなので、変更すべきでないのかと思う。
最初から選べる選択肢がどのような処理を行うものかもドキュメントからわからなかった「「default-posting-pipeline」「default-owner-pipeline」「vergin」」
そのため変更した場合の影響が全く未知数である。
「コンテンツの除去・通過」は「いいえ」（推奨）
「コンテンツの除去・通過」から「HTMLをプレーンテキストに変換」までは一連の設定のようで「いいえ」とすると機能しないようだ。
詳細は以下リンクを参照
https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/handlers/docs/filtering.html
現状では検証が行えておらず、動作がよくわからない。おそらくは必要性もかなり低いので、検証を優先しない。
添付ファイルやメールの形式を指定して、ブラックリストホワイトリストの登録をして処理決定をする機能と思われる。
有効にする場合、ML管理者は機能を検証し、動作を正しく理解した上で設定を行うこと。

DMARC対策

メールシステムは1980年代から90年代にかけて標準化・普及されたが、現代環境でスパムの多様・高度・多数になったことなどにより、メールシステムの標準に準じてこれまで行われてきた運用に支障がきたされるようになった。
その対策として、ドメイン認証という送信元の正当性を確かめる方法が考案され、現在のメールシステムで一般に利用されている。
DMARCはこのドメイン認証の一部を指す。ドメイン認証はDMARCのほかに、SPF,DKIM,ARCと呼ばれる標準仕様を元に構成される。

mailmanは過去制定された、メーリングリストの形式に則り実装されているが、メーリングリストの形式は比較的現代に制定されたドメイン認証に対して、合わない部分がある。
概要としては、MLの転送を挟むことで送信元IPを検証するSPFが検証できなくなり、MLの機能によりメールの書き換えを行うことでメールの改竄を検証するDKIMも検証できなくなる。
これによりメールの受け取り側が、メーリングリストを通したメールを正当でないメールとして評価するようになり、メール送信元がこのような正当でないメールを拒否するポリシーをDMARCに準拠して公開している場合に、メールの受信が拒否される。
また、ポリシーによらず、単に信頼性の低いメールとして評価されやすくなる可能性がある。

なお、ARCはこの転送で損なわれる正当性を検証するために、転送を担当したシステムが新たな署名を行うものであるが、この署名者の信頼性を担保できないという理論上の限界により信頼されない場合がある。

この対策として、mailmanはこの項目で設定するような機能を提供している。
設定の詳細は以下を参照
https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/rules/docs/dmarc-mitigation.html

「DMARCの緩和処理」は「From: をリストのアドレスに置き換える」(推奨) これを設定すると、転送によってDMARCの設定判定に問題が発生するメールについて、処理を行うようになる。
以下、各設定の詳細
- 「From: をリストのアドレスに置き換える」では、配信されるメールについてFromがリストのアドレスになり、Repry-toに元のFromを設定される。
  「From」つまりはメールの送信元、これをMLを運用するサーバに変更することで、メールの送信元が正当に検証できるようになる。
  ただし、メールの元の送信元が書き換えられるため、過去の運用と全く同様の利用ができないことについて、すべての利用者は理解が必要だろう。
  mailmanでは、この送信元に際し、元の送信元アドレスを「Reply-To」という返信先を設定するデータをメールに付与するため、理論上は実際の運用に支障をきたさない。
  「返信先:Reply-To」が設定されているメールに対し、大抵のメールクライアントは、通常の返信先としてこのアドレスを選択するようになっている。ただ、これをよく理解していないユーザが、「送信元:From」を選択的に手動で返信先のアドレスとして利用している様子が見られるが、このような操作は「返信先:Reply-To」が設定されているメールに対し適切ではない。
- 「From: をリストの投稿用アドレスにし、投稿されたメッセージを添付します。」でも、同様にFromがリストのアドレスになり、Repry-toに元のFromを設定され、元のメールは配信メールの添付ファイルとなる。
  元のメールが添付ファイルとして得られるため、メールを別途扱えば、元のメール直接扱うことができる。
  元のメールをMLの形式で扱うか、添付ファイルで扱うか、理論上はどちらでも問題無いため、どちらを良しとするかは、利用者やML管理者の感覚次第である。
  ここでは、より直観的にわかりやすそうに思った「From: をリストのアドレスに置き換える」を推奨として記載している。
- 「DMARCの緩和なし」を設定すると、上記の通りMLの転送や処理によってSPFやDKIMが損なわれ、送信元のDMARCポリシーにより、メールが到達しない場合がある。 DMARCは世界的な標準として過去5年ほどで急速に導入が進んでおり、ポリシーについても、より厳しいものを採用するべきと各所で提言されている。
  そのため、今後MLを利用したメール受信において、対策を行わないことは不可能であり、この設定利用すべきではないだろう。
- 「メッセージを拒否/破棄する」は、設定すべきでない。送信元が正当に送信したメールについて、衛陶であることを理由に拒否・破棄することは意味不明である。
「DMARC対策を無条件に実施」は「いいえ」(任意)
「いいえ」の場合、送信元のDMARCポリシーがnoneや未定義の場合は、緩和処理でFromの書き換え設定にしていても、処理の対象としない。
このため、メールの変更が限定的になり、利用者は多くのメールを従来の操作感で利用できる。
また、ドメイン認証において、より正確な処理が行える可能性がある。
ただし、一部のメールだけ違う形態で届くため、正しく理解していない場合に混乱する可能性があるかもしれない。
「はい」とするとすべてのメールに処理を行うので、利用者にとってはわかりやすくなるように思う。
ただし、スパムメールなどを転送してしまった場合に、送信元が自身のアドレスとなってしまうことから、対策により慎重になりたい感覚がある。
これを「はい」にする場合、ヘッダーフィルターの設定を必ず行いスパムを送信しないよう運用すること。
設定の如何によらずスパムを頻繁に転送するようなメール転送サーバや利用者は、既に致命的に問題なので、前提として対策がちゃんとあるならどちらでもいいかもしれない。
「DMARCアドレス」は利用しない(推奨) 「DMARC対策を無条件に実施」に対して、この対策を行うFROM送信元についてアドレスを条件に設定できるようだ。
これが必要になる場合がとくに思いつかないので、おそらくは使わないと思われる。
「DMARC拒否通知」は利用しない(推奨)
「メッセージを拒否する」を設定した場合に、返信されるメッセージを指定できるようだ。
利用することは無いはずである。
「DMARCラップされたメッセージテキスト」は利用しない(推奨)
「From: をリストの投稿用アドレスにし、投稿されたメッセージを添付します。」を選んだ時のメールの文面を設定できるようだ。
ユーザ向け説明を書けばわかりやすくなるかもしれない。

ダイジェスト

検証をしておらず以下記載は正確でない可能性が高い。
利用機会はあまりないと考えているため、検証の予定は現時点で無い。

概要としては、メールを随時では無く、ある程度まとめて送信することで、メールの総量を減らすための機能のようだ。

おそらくだが、メンバーオプションの配達モードと合わせて設定するものなのだと思われる。

詳細は以下を参照
https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/handlers/docs/digests.html

「ダイジェストを有効化」を「いいえ」にする(推奨)
上記の通り利用を想定していない。
「ダイジェストを定期的に送信」を「いいえ」にする(推奨)
有効化しない場合設定の意味はないかと思うが、いいえとしておく。
「ダイジェストの発行頻度」は「毎月」(任意)
有効化していないため、設定の意味はないが、任意のもので良い。デフォルトは「毎月」
「ダイジェストのしきい値」は「30.0」(任意)
有効化していないため、設定の意味はないが、任意のもので良い。デフォルトは「30.0」

メッセージ受付

「使用可能なエイリアス」は適切なものを設定する（任意）メールの宛先(TO,CC)にML自身のアドレスが含まれていない場合、「明示的な宛先設定」が有効であれば「メッセージの宛先にメーリングリストが明示されていません」の理由で保留になる。
例えばBCCに含まれている場合や、転送で別のメーリングリスト等を通してメールが来た場合だ。
ただし、この項目に設定をしたアドレスが宛先(TO,CC)に含まれていた場合は許可される。
「明示的な宛先設定」は「はい」を選択（推奨）
上記の通り、宛先に対するフィルタを有効にするかどうかの設定。
該当アドレスを、別のリストに参加させたりやエイリアスを設定する場合は、「使用可能なエイリアス」の設定を行うこと。
「投稿アドレス宛の申請を保留」は「はい」（推奨）
mailmanでは、特定の管理アドレスに定められた形式のメールを送ることで、購読(MLへの参加要求)や脱退の要求ができる。
これが管理アドレスでは無く、通常の配信用に送られた際に検出するかどうかの設定のようだ。
メールの件名がsubscribeやunsubscribeの時、保留すると思われる。
このようなメールが実運用で発生するとは思えず、またMLを現状このような形式で運用しているものは学内で確認されていないため、設定はどちらを選んでも問題なさそうだ。
検証をしていないため、推奨はデフォルトの「はい」とする。
詳細は以下
https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/rules/docs/administrivia.html#administrivia
「メンバーがリストに投稿したときのデフォルト処理」は「デフォルト処理」or「保留」(推奨)
実際何を選ぶかは運用によると思うが。デフォルト処理以外を選ぶと、「明示的な宛先設定」等他のフィルターのチェックを行わずにその処理が行われるようだ。
これ以外の選択はするべきではない。

メンバからの投稿を許すのであれば「デフォルト処理」を選ぶと良い、また利用頻度の高い担当アドレスなどとして使う場合には、「デフォルト処理」が優れているだろう。

あるいは一旦すべてのメールを保留にして管理者が配信するかどうかを決めたい場合は「保留」を選ぶ。
基本的に通知に使うようなアドレスであれば、メンバからの返信は、他メンバに知らせるべきでない内容を含む可能性もあるため「保留」が良いだろう。
あるいはメンバを名乗るスパムがフィルターとりきれていないなどあれば「保留」とするほかないだろう。
メンバが多数になるようなアドレスにおいては、管理者の責任としてはすべてのメールを「保留」として送信を確認するべきだろう。

「非メンバーがリストに投稿したときに実行されるデフォルトの処理」は「保留」(推奨)
メンバー外からのメールはスパムや不要なメールを含みやすいため、基本は保留として、配信前に管理者が確認すべきである。
メンバー以外からの投稿を想定しないアドレスであれば、拒否・破棄でもよい。
MLでは多数の宛先にメールを配信する。そのため、アドレスがスパムの標的となり拡散した場合、ドメインに致命的な影響を与えることがあることを管理者はよく認識しておく必要がある。
ただし、スパムの対策がドメインやMLで客観的に十分に行われており、そのドメインの管理者が許可するのであれば「デフォルト処理」を設定してもよい。
なお対策の十分さについて、例えば1日に1通スパムが配信されるならそれは十分でないだろう。
「緊急時の投稿処理」は「いいえ」（推奨）
もし、MLがスパムの攻撃対象になるなどで異常な配信を行うようになり、管理がままならなくなった場合、「はい」にする。
全メールが保留されるようになるので、対策を行い、MLが正常に運用できることを確認の上で「いいえ」に戻す
「最大メッセージサイズ」は100以下、初期は40以下(推奨)
原則として多数の人に配信されるメールの容量は、可能な限り小さくされるべきである。

一般的なテキストベースのメールで100KBのメールを作る場合、1万文字以上が必要になり、返信などが重なった場合ありえなくはないが、一定は制限を行うことが妥当だ。

なお、ファイルの添付によりメールの容量が大きくなる場合は、100KBは簡単に超える。
これは、容量が小さいのではなく、メールにファイルを添付することが間違いであると理解する必要がある。
上記の通り、「多数の人に配信されるメールの容量は、可能な限り小さくされるべき」であり、ファイルを送りたい場合、添付では無く、NUSSや、Sharepointサイトを使った方法を検討すべきだ。
(もちろんだが、間違っても外部のファイル共有サイトやソフトを使ってはならない)

MLに限った話ではないが、全ての利用者は、メールの利用法や、ファイルの共有方法について、より正しく理解し運用することが求められる。

「最大受信者」は10(任意)
ToやCCがあまりに多数含まれているメールは不審なメールとして扱われる。
デフォルト値は10であり、実際一般にTOやCCが10を超えるメールはあまりないだろう。
本学のメールにおいては、まれに10以上のものもあると思われるので20くらいまでは追加してもなんら問題無いと思われる。
「投稿を承認する非メンバー」から「投稿を破棄する非メンバー」までの設定は(任意)
「非メンバーがリストに投稿したときに実行されるデフォルトの処理」の前に行われて、優先してこの処理が実行されるもののようだ。
MLの運用について分析し、正しく設定を行うと良い。
先の設定の通り基本的には、非メンバーのメールはすべて拒否とされていると思うが、特定の送信アドレスは許可したい、学内からのメールは許可したい、などがあればここで設定することで、安全性を保ったまま可用性の向上を見込める。
この際「投稿を保留する非メンバー」は全アドレスを意味する「^.*」を設定するべきだろう。

アーカイブ設定

「アーカイブポリシー」は「このリストをアーカイブしない」(推奨) ※公開アーカイブは(禁止)
当然ではあるが、メールをアーカイブとして保存することはサーバの容量を使用するため、ドメイン管理者の許可が得られた時のみ利用すること。そうでない場合は、このリストをアーカイブしない」とすること。

また、おそらくは機構で運用するどんなメーリングリストでも。アーカイブの公開を想定して運用するようなことはあり得ない。
そのため許可を得て利用する場合でも、「非公開アーカイブ」を必ず選択すること。
「公開アーカイブ」にした場合、このURLにアクセスできるすべての人が、ログインなどせず、すべてのアーカイブを見ることができてしまう。

なお、現在統合サーバでアーカイブを有効にしているMLには、多数のスパムメールを保存し容量を無為にしているものがあるようだ。
運用するのであれば、管理も必ず行うべきである。
また、アーカイブだけに限らないが、最低限スパム対策は必須といえる。

「有効なアーカイブソフト」「アーカイブのレンダリングモード」については利用を想定しないため解説しない。
アーカイブを利用する場合、各管理者の自助で行うこと。

入退会ポリシー

「解放」はすべて許可されるようだ。絶対に設定すべきではない。
「審査」はメンバの入退会にML管理者の許可を必要とするかどうかのことのようだ。これはまず必須だろう。
「確認」は参加を要求するアドレスが有効なものかをシステムで確認するかどうかを指しているようだ、これはMLに登録する際にメールが来て確認するようなフローを指しているもののように思われる。

「入会ポリシー」は「確認後、審査」(必須)
多くのリストで、メンバが勝手に参加可能な状態は許容できないはずである。
場合によっては、機密情報の漏洩にもつながり、極めて危険である。
あまりないかと思うが、もし入会希望を受け付ける運用をする場合でも、入力間違いの防止などのため、確認を有効にしておくと良い
「退会ポリシー」は「審査」(推奨)
メンバーが勝手に脱退可能であっても、機密の流出はないと思われる。
ML管理者が許容するのであれば、審査の必要もない。
しかし、実際にはML管理者による操作でのみメンバ管理を行うことが学内のMLでは現実的であろうと思うので
推奨を「審査」とする

バウンス処理

バウンスとは、送信したメールについて、宛先のアカウントが存在しない、スパムと判定され受け取りを拒否されたなど、宛先に到達しなかったメールについて、そのエラーを知らせるために返信されるメールや、この一連の動作を指す。
バウンスが発生した際、発生した件数をユーザのバウンススコアとして扱い、閾値を超えたユーザについてメール送信を停止する機能。
復帰にはML管理者による操作が必要になる。
スパムメールなどを転送する設定では頻繁に起きるが、バウンス処理を行わない対策はまずい。
スパムをばらまくことになるし、サーバのレピュテーションを下げうると思われる。
基本的にはバウンスが発生しないよう、普段から管理を気を付けておくことが望まれる。
https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/model/docs/bounce.html#bounces

「バウンス処理」は「はい」を選択（必須）
「バウンススコアの基準値」は5（推奨）
「バウンス情報の有効期間」は「7d」(推奨)
「バウンススコア増加時にオーナーに通知」は(任意) 1件でも届かないところがあったら知りたい等、すこしでも発生したら気づきたいのであれば「はい」としてもいい。
ML運用の大勢に影響がないと考えており。デフォルトでは「いいえ」としている。
「無効化時にオーナーに通知」は「はい」（必須）複数発生している場合には、明らかな問題があるため対応が必要になる。
「退会時にオーナーに通知」は、「はい」（必須）続く設定で、一定回数の警告を送り、対応が無かった場合、該当ユーザは退会させられるようだ。
ただこの動作について再現や検証を試していない、しかし記載通りの動作なら管理者への通知は必須だろうと考える。
「識別できないバウンスを転送」は「メーリングリスト管理者」(必須) なぜかこの設定に関する記載が公式ドキュメントのどこにも存在しない。
また、検証できていないため、詳細は不明。
MLに関する通知についてはML管理者が知るべきため「リスト管理者」を必須とする。
おそらくは記載の通り、何らかの問題あるバウンスメールについて宛先を設定するのだろうと思う。
「バウンスによる無効化の警告間隔」は「7d」(推奨)
「バウンスによる無効化を警告」は「3」(推奨)

Newsgroup Gateway

過去に利用されていた、メールを用いた情報共有の形式としてニュースグループと呼ばれるものが存在していたようだ。
現在はおそらく使われていないため、無効化を推奨とする。もし必要な場合はかくML管理者で自助にて設定を行うこと。
推奨値は、mailmanのデフォルト設定とする。
https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/rules/docs/news-moderation.html

「メーリングリストに転送」は「いいえ」(推奨)
「ニュースグループへの転送」は「いいえ」(推奨)
「関連するニュースグループ」は設定しない(推奨)
「ニュースグループの承認」は「承認されていません」(推奨)
「NNTPに件名プレフィックスを適用」は「はい」(推奨)