ホーム > 春日キャンパス情報基盤システム > メーリングリスト管理メモ

メーリングリスト管理メモ

メーリングリストのリスト管理作業に関するメモランダムです


管理用パスワードの変更

これはメールで連絡されてくるリンクページを開き、
やはり連絡されてきたパスワードでページに入ります。

ページ表示にもあるように、その際 Cookie が使用可能になっていることが
必要ですので、ブラウザをそのように設定してください。
 ・IE であればメニューの「ツール」→「インターネットオプション」
  →「プライバシー」
 ・Netscape であればメニューの「編集」→「設定」
  →「プライバシーとセキュリティー」→「Cookie」
といったところかな。

無事ログオンできれば「XXX メーリングリスト管理:全体的オプションの部」
のページに入ります(XXX はメーリングリスト名)。
左上、「設定分類」の下(画面サイズによっては左下」にある項目が、
管理用オプションを種類別にまとめたページへのリンクで、
現在表示中のものが [...] で囲われています(この時点では [全体的オプション])。

その下の「パスワード」をクリックすると「リスト管理者パスワード変更」
という見出しのあるページになります。
右側の「司会者パスワード」はとりあえず無視して、
左側の「管理者パスワード」にパスワードを入力します。

その上で、ページ下中央にある「変更を送信する」ボタンをクリックします。
他のページでも同様ですが、この「変更を送信する」ボタン(ページによっては
違う文字列が表示されます)をクリックしないと、設定した内容、
今の場合パスワードが更新されませんので注意。

このクリックによって同じページが再表示されますが、これは FORM の実行によって
前のページに上書きされているので、ブラウザの「戻る」などやると、
前のページに表示が戻ります。これは設定更新前の表示になりますので、
更新した設定内容とは食い違います。そこでブラウザの「再読み込み」を必ず行い、
常に最新の情報が表示されるように心がけてください。
これは管理作業全体を通じて言えることで、各ページにしつこく
 「警告: この設定を変更すると, 他の画面の表示内容と一致しなくなる
  かもしません.」
と出るのはこのことです。

上記のようにして管理者パスワードを変更しても、新パスワードはメールで
通知されたり、またメールで取り寄せることはできません。パスワードを忘れないで
ください。また、複数の管理者が一つの管理用パスワードを共有しているので、
管理者同士で変更の連絡を忘れないようにしてください。

Mailman全体の管理者(サイト管理者)は任意のリストの管理画面にログインできます。
したがって,パスワードを忘れた場合はシステム管理グループに連絡すると、
パスワードを再発行できます。

これに対し、一般会員にもパスワードが付与されますが、これは忘れた場合、
メールで取り寄せ可能です。

管理者パスワードは、リスト内のいわば「マスターキー」の役割を果たします。
つまりこの管理者パスワードによって、一般会員の個人ページにも自由に入ることが
できます。
つまり個人ページへの入り口は、その個人本来のパスワードの他に、
管理者パスワードというもう1つの口もある、ということです。

管理者ページへの認証もこのパスワード1つだけで行われますので、
くれぐれも安易なパスワードは使わないで使ってください。

なお、ブラウザ内で他ページに移動したりした場合には(Cookie がまだ有効ですので)
管理者ページに(パスワードを打つことなく)戻ることができます。
Cookie を無効にするには「ログアウト」をクリックして出てください。
 # ブラウザ全体を終了するのでもかまいません。

サブジェクトにリスト名や連番を含める

・subject_prefix(件名の先頭に付ける語句)
 このデフォールトは、[ML名] だったと思います。
 これがあることで、他のメールと見分けがつきやすいし、
 ソートしてその ML への投稿だけを取り出すのも容易になります。

 ここに連番をつけることができます。
 書き方は C の printf 書式とほぼ同じで、例えば5桁で先頭ゼロ詰め
 にするなら、[ML名: %05d] のようにします。
  # ゼロ詰めか空白詰めかに関わりなく、連番の桁数は十分確保してください。

 連番があるとメール同士の前後関係がすぐわかりますし、参照もしやすく
 なります。しかし一方、問題点として、件名でソートしてもこの連番順、
 したがって日付順と同じになってしまい、タイトルごとに仕分けられません。

 これを解決するには、prefix 部分を無視してソートすればよいことは別便で
 述べました。これ自体はそんなに難しい話ではなく、ソースに手を入れられる
 ならちょっとした修正で済むはずです。

 しかし今のままであれば、管理者としては、番号がつくメリットと、
 ソートできないデメリットとを天秤にかけての選択が必要です。

返信先の指定

・「Reply-To:ヘッダの書き換え」の項目群は、説明文の書き方がわかりくい
   ので注意が必要です。
  # そうでなくても英文とチャンポンになっていたりして出来が悪い。

 先に Reply-To(=「返信先」)の説明をしておきます。
 受信したメールに「返信」すると、通常はメールの発信者(From: フィールド
 のアドレス)に返信アドレスが設定されます。
  # 「全員に返信」といった機能があれば、cc されたアドレス等も
  # 返信アドレスに含まれますが、それには立ち入りません。
  # また実際の動作は、メールリーダーやユーザ設定に依存します。

 これに対し、(発信者側で)発信アドレス以外を返信アドレスに指定したい
 場合もあります。例えば、一時的なアドレスからメールしているので、
 返信は本来のアドレスに送ってほしいとか、問い合わせ専用アドレスに誘導
 したいとかいった場合です。
 その場合、メールヘッダに Reply-To: フィールドでアドレスを指定すれば、
 こちらのほうが From: のアドレスに優先して返信先に選ばれます。
 Reply-To フィールドは多くのメールリーダーで、「返信先」といった名称
 により設定できます。
  # これらの点も、実際の動作はメールリーダーによって異なります。
 その裏返しとして、Reply-To が付与されていなければ、返信は発信者宛
 というのがデフォールトです。

 メーリングリスト(ML)でどういった返信先を設定すべきかは、ML の性格に
 依存します。相互の意見交換が活発なディスカッション型 ML では ML そのもの
 を返信先とするのが適切でしょうし、少数の発信者からの告知・案内といった
 一方向的な伝達が中心のアナウンス型 ML では発信者自身か、その他の
 連絡先を返信先とするのが妥当でしょう。
 もちろんいずれの場合でも、そういった標準的な返信先以外を指定したい
 場合もあります。例えばディスカッション型でも、会議の出欠をとるといった
 場合には、返信は ML 全体ではなく、取りまとめ役個人に送られれば十分です。

 さらに言うと、返信先を ML 全体にしておくと、会員の中には、発信者個人に
 返信しているつもりで、ML 全体に不適切な投稿、中にはトンデモな個人情報を
 含んだ投稿をしてしまうケースが後を絶たないというのが現実です。
  # 返信アドレスをきちんと確認してから発信する、なんてことをしない
  # 人がやたらいる、ということ(私自身もときたまやるけど)。

 Reply-To の設定は、発信者自身と、ML server の2段階にわたることに
 注意してください。特に ML server のほうが後ですから、発信者の設定を
 どうするかの決定権があります。ここでの設定項目群もそれに関するものです。

 そこで順番に見ていきます。以下では次の記号を用います。
    S: 発信者、ないしそのアドレス
    M: メーリングリスト、ないしそのアドレス
    B: reply_to_address で設定されたアドレス(後述)

    S(-): 発信者が Reply-To を付与せず発信
    S(A): 発信者が Reply-To にアドレス A を付与して発信。
       (A は S と同じであってもなくてもかまわない)
 
  ・first_strip_reply_to は、S(A)(発信者によって付与された Reply-To:
   もしあれば)をどうするかです。S(-) であれば無関係です。
     # 説明文の「Mailman によって付けられたか」はよくわからないので、
     # とりあえず無視します。
   「いいえ」を指定すると、S(A) は(この段階では)素通し、
   「はい」を指定するとここで削除です。
   以下、「いいえ」を 0、「はい」を 1 という記号で表します。

  ・reply_goes_to_list は「投稿者」、「このリスト」、「別のアドレス」
   の3通りからの選択で、以下これらを a, b, c という記号で表します。
   a.「投稿者」: これは一読すると、発信者アドレス S が Reply-To として
    設定されるように思えますが、そうではなく、Reply-To は何も付与
    されません。(S(-) であれば返信は S 宛になることに注意)
   b.「このリスト」: Reply-To: M が設定されます。
       S(A) であれば A, M の両方が設定されます。
   c.「別のアドレス」:
    これは次の reply_to_address とセットで使います。
    ここで設定されたアドレスを B とします。
    B が空のままで「別のアドレス」を設定すると、
    実際の設定は a:「投稿者」になります。
    B にはアドレスを1つしか指定できません。
    複数のアドレスを指定するとエラーとして扱われ、
    前の設定のままになります。
   
    B が設定されている場合、S(-) であれば B が、S(A) であれば
       A, B が Reply-To に設定されます。

 以上をまとめると以下のようになります。
 ここで ML での上記 {0,1}x{a,b,c} の設定を M(0a), M(0b), ..., M(1c) のように
 書きます。また上述のように、S は発信者アドレス、M は ML アドレス、
 A は発信者が Reply-To 設定したアドレス、B は「別のアドレス」として設定
 されたもので、結果の - は Reply-To が設定されないことを表します。

     S(-) S(A)  ← 発信者の Reply-To 指定
  -------------------------------------------------------------
  M(0a)  -  A   ← 実際に設定される Reply-To: 以下も同じ
  M(0b)  M  A, M
  M(0c)  B  A, B
  M(1a)  -  -
  M(1b)  M  M
  M(1c)  B  B

 現在使っている fml の場合、当初の設定は M(だけ)が返信先になる、
 つまり M(*b) に相当するものでしたが、後に「デフォールトでは ML が
 返信先に設定されるが、発信者が明示的に返信先 A を指定した場合には
 そちらを優先する」という設定に変更してもらいました。
 ディスカッション型 ML では一番妥当な設定と思いますが、
 上記の Mailman の機能では、これを実現することはできません。

 一方、アナウンス型では M(0a) ないし M(1a)、問合せ先などを一元化する場合には
 M(1c) が妥当な設定でしょう。
 個別会員に好き勝手な設定をさせないためには、M(1*) を選ぶことになります。

 どういう設定にするかは完全に ML のポリシーの問題なので、
 最適と思われる選択をしてください。
 Mailman のデフォールト設定は M(0b) だったと思います。

会員や管理者への通知

・「通知」の項目群について、私自身の基本ポリシーは、
 「個別会員にはあまり余計な通知は送らない、一方管理者には(煩わしいけど)
  できるだけ詳細な情報を集める」というものです。

・そこでですが、最初の「パスワード備忘通知」(send_reminder) は
 デフォールトでは「はい」になっていますが、「いいえ」とすべきでしょう。
 こんなもんを毎月送られたらたまらん。

・続く welcome message, goodbye message についてはご随意に。
 ただ、いくつか考慮点を述べておきます。

 ・welcome message では個別会員ページの URL や会員パスワードが
  あわせて通知されます。したがってそういった情報を送付したいなら、
  welcome message は送るべきです。
  特にパスワードについては、ここで送付しないと各人がメール取り寄せに
  なります(管理者にも個別パスワードは直接にはわかりません)。
  パスワードとか個人設定についての問い合わせが多数寄せられる懸念はあります。
  私自身は個人設定は可能な限り隠しておきたいのですが、
  そうはいかない面もあります(後述:「保存書庫」閲覧など)。

  これに対し、総合案内ページや個人設定ページ、パスワードの取得方法
  などを ML への投稿で案内し、welcome message は発送しないという
  選択肢もあります。(もっともメールが送信されることは同じなのだから、
  やはり welcome は発送すべきかしらん。)

 ・今回は既存 ML の移行が中心で、新規 ML の作成や新規会員登録が主眼では
  ありませんから、その点についての考慮も必要です。

 ・複数の ML に属している人は、自分が属している全 ML に横断的に
  アクセス可能です。(個人会員ページの「他のリストへの入会状況」参照)
  したがってある ML からは welcome が来て、他からはこないというのも
  おかしなものではあります。その一方、同じような welcome がやたら
  来るというのも煩わしくはある。全 ML に対するパスワードを統一して
  しまえば、どこも同じようにアクセスできるからです。
   # パスワードや設定を所属全 ML で同一にしてしまうことの
   # 可否はここでは触れません。
  私の場合、属している全 ML から welcome が来ると(自分が管理している
  ものも含めて)ざっと 15 個ぐらいは来そう。

・その次の admin_immed_notify, admin_notify_mchanges は上記の理由で
 「はい」(これがデフォールトだっけ?)、
 最後の respond_to_post_requests も「はい」にしておいたほうがいいでしょう。
 これは個人会員宛のメッセージ発信ですが、「保留中」という情報自体は必要
 なので、例外的に「はい」。

   学外にアドレスとかの存在が知られている ML の場合、
   非会員投稿とかでやってくるメールのほとんどは SPAM であり、
   返信してもエラーメールでバウンスしてくるのが関の山ですから、
   そういう場合には「いいえ」(デフォールト?)にしておいたほうがいいですね。

   学内リストとかならそういった心配は低いので「はい」でもいいですが。

ダブリ

・「その他の設定」項目群は、こんな名前がついてますが、結構重要なものがあります。
 が、最初の emergency や administrivia, host_name は無視、デフォールト通り。

・「新入会員のデフォルト設定値」(new_member_options)
 4項目ありますが、ここにある説明では長いので、
 「会員管理...」→「会員リスト」の対応する項目名:
   「隠れ会員」、「受領」、「控え無」、「ダブリ無」
 で言及します。
 デフォールト設定では「ダブリ無」だけチェック、他はチェックなしだったと
 思いますが、下記のようにこれは変更したほうがいいでしょう。
 ・間の2つ、「受領」、「控え無」はデフォールト通り、チェックなしで
  いいでしょう。ただし、「控え無」は「ダブリ無」とも関連します。

 ・「隠れ会員」は会員リストの公開と関連しますので、詳しくは
  「プライバシー・オプションの部」のところで。
  簡単に言えば、これは会員リストの公開に関係する項目で、「隠れ会員」なら
  公開リストに掲載されません。
  ただ、会員リストそのものを公開すべきかの可否があるし、昨今の個人情報に
  うるさい折柄、デフォールトでは個人情報を公開しないほうに設定して
  おいたほうがいいでしょう。その上で、公開したい人は個人設定で公開できます。
  だから「隠れ会員」=「会員アドレスを隠します」の項にはチェックを入れるべき。

 ・「ダブリ無」についてはすでに [mailman-ml 19, 20] あたりで触れました。
  「控え無」についてもほどんと同じ話が当てはまります。

  結論から言えば、「ダブリ無」を設定すると、これまでの ML の通常の振る舞い
  とは違った形でメールを受け取ることになり、そうでなくてもいろいろ
  使いにくいことになってしまうので、ここはチェックなしにしておくべき、です。
  どのみち、ダブリが 100% 解消されるわけでもないし、そんなベラボーな数の
  重複があるわけでもないから、手動で削除すれば済むことでしょう。

  一応、「ダブリ無」を設定した場合の動作を確認しておきます。
  これは同じメールが同一アドレスに複数配送されることを避けるという機能です。
  具体的なケースでまとめておきます。
  ・発信者 S が(自分が属する)メーリングリスト M に投稿を行い、
   同じメールの To:, cc: に自分のアドレス S も設定した場合、
   To, cc に基づく配送は行われるが、M からの配送は行われない。
  ・ただし、To, cc でなく、bcc を使った場合、つまり「To: M, bcc: S」
   とした場合には bcc による配送と M からの配送の両方が届く。
  ・M のメンバーである B に対し、S が「To: M, B」とした場合
   (To は cc でも同じ)、B には S からの直接配送だけが届き、
   M からの配送は行われない。
  ・S が2つのメーリングリスト M1, M2 に属しているとき(M1, M2 は
   同一の Mailman server 下にあるとする)、「To: M1, M2」によって、
   M1, M2 の両方からの配送が届く。

  最後のケースは、登録アドレスを ML 間で横断的に管理しているにも関わらず、
  それをチェックしてはいない、ということですね。

  で、M からの配送がないと、ヘッダに ML 名や連番のついた、さらには返信先
  などが設定されたメッセージを受け取れないことになり、何かと不自由です。
   # 私など、ファイルサイズが少し大きいことは承知で、To, cc されたほうでは
   # なく、ML からのものを保存している。
  また保存書庫には To, cc の情報は表示されませんから、特に上の B さんの場合、
  なぜ ML からの配送がないのか、すぐにはわからないという問題もある。

  さらに、実際に多数の重複が生じるのは、複数の学会 ML から同一の案内が
  送られるような場合(本文に「同一案内を重複して受け取ったらごめんね」
  とあるようなもの)であって、これに対しては無力です。

 というわけで、以上まとめると、この「新入会員のデフォルト設定値」については、
 「隠れ会員」はチェック、他はチェックなしが推奨です。

・最後の2つの List-* 関係: include_rfc2369_headers と include_list_post_header
 は、確かにうるさくはあるし、これ丸ごと引用されたメールが増殖して膨れ上がる
 といった問題はあるのですが、一応推奨にしたがってデフォールト通りとしましょう。
 (ただし、アナウンス専用 ML の場合、List-Post は不要)

保存書庫

「保存書庫オプション」については、設定はデフォールト通り。
 # もっとも投稿数の少ない ML の場合、archive_volume_frequency は
 # 大きくしておいたほうがいいでしょう。とはいっても、「毎月」が
 # 「毎年」になるだけだけど。
 # 逆に投稿数の多い ML についても、あまり小さな単位に分けるのは
 # 勧められない。

「保存書庫」は有用な機能なのでいろいろ活用できるのですが、
いろいろな問題があるのでぜひ解決してほしいです。

例えば共同作業で交換する文書ファイル類のアーカイブといった
活用(悪用?)を考えていたりする。

投稿メールの最大サイズ

「全体的オプション」ページで残っていた
「投稿メール本文の最大サイズ」(max_message_size) について。
これは「設定分類」の「添付ファイルの除去」とも関連しますし、
配送保留となった場合の「未処理の申請」とも関係するので、
合わせて述べます。

===========================================================
まず「最大サイズ」そのものについて。

デフォールト設定は 40KB です。
これは投稿がすべてプレーン・テキスト形式である場合には、
まあ妥当な設定とは言えるでしょう。

ところが昨今では、WORD, Excel, PowerPoint, PDF や画像ファイル
などを添付したメールが横行しています。
また送っている本人が知ってか知らずか、必要もないのに
HTML 化したテキストメール(HTML だけだったり、
multipart/alternative で平文と HTML とを併記されたり)
といったものもあります。
こういった投稿の場合、40KB などあっというまに超えてしまいます。

この段階で、管理方針として次のような選択肢が生じます。
 (A) 添付ファイルを一切認めない。
   添付されていた場合でも削除して本文だけを送付する。
 (B) 添付ファイルそのものは禁止しないが、
   (最大サイズを小さめに設定しておくなどにより)
   特に巨大な添付ファイル付きメールを送信するかどうかは
   ML 管理者が決裁する。
 (C) (最大サイズを大きく設定しておくことで)
   添付ファイルのある場合でも、できるだけフリーパスで通す。

======
許容する最大メールサイズは KB 単位で設定でき、0 を指定すると「無制限」
になります。ただしこれは ML server での話であって、実際のメール配送を
行うメールサーバーでの制限値があれば、それも適用されます。(本システムでは30MB)

で、具体的にどのような値に設定すべきかですが、
デフォールトの 40KB だと、WORD や Excel のファイルは、よほど小さいもの
でないと、まず通りません(通らないとどうなるかについては下記)。

一方、300KB、まあ 500KB ぐらいあれば、普通の文書(テキストのみ)であれば
WORD にせよ PDF にせよ、多くは通ります。
しかし画像が取り込まれていたりすると、1MB を超えてしまうことも珍しくありません。

1MB ぐらいになってくると、「何を通すか」という問題だけでなく、
サイズそのものが問題になってきます。
例えばメールスプールで使用できる容量が小さいと、巨大メールは大きな負担に
なりますし、学内LAN接続 とかならまだしも、プロバイダとか携帯とかで
転送速度が遅いネットの場合には転送時間も問題です。

実際にどう設定するかは ML の性格にもよるし、各管理者の判断になりますが、
基本的には「これ以上のサイズを送られたら困る」といった値を設定する
ことになるでしょう。
会員が広い範囲に及ぶ(地域的にも、練度等においても)場合には
配送等に問題がないように小さめに設定しておく、
一方、共同作業用とかで、文書ファイル等が頻繁に交換されるような場合、
大きな値、さらには無制限に設定しておく、といった具合です。


*** 管理者(司会者)による承認処理 ***

どのような最大サイズを設定するにせよ、(無制限でない限り)
制限を越えたサイズのメールが来ることはありえます。
そこでその場合にどうなるかを述べておきます。

この場合には管理者の決裁によって、どうするかを決めることになります。
 # 以下では「管理者」とだけ言及しますが、実際には
 # 司会者 (moderator) も決裁可能です。

そのような決裁は、サイズオーバーだけでなく、例えば(非会員投稿を
禁じている場合)非会員からの投稿があった場合などにも生じますので、
そういった場合についても同様に処理してください。

まず管理者宛に次のようなメールが届きます。
========================================================
件名: xxxxxx-ml への foo@slis.tsukuba.ac.jp の投稿は承認が必要です。
本文:
以下のメーリングリストへの投稿は、リスト管理者の承認が必要です。

    リスト:  xxxxxx-ml@slis.tsukuba.ac.jp
    発信者:  foo@slis.tsukuba.ac.jp
    件名:    quota limit test (quota: 20KB)
    理由:    メールの本文が長すぎます: 36025 バイトありますが, 制限は 20 KB です

適当な時に以下の URL で承認作業をしてください.

    https://mail.slis.tsukuba.ac.jp/mailman/admindb/xxxxxx-ml

quota limit test (quota: 20KB)

保留されているメールを破棄するには, Subject: (件名) ヘッダに手を加え
ずに返信してください. SPAMメールなら, 破棄してください. リストへの配付
を承認する場合は, Approved:ヘッダにこのメーリングリストのパスワード
を付けて返信してください. Approved: ヘッダは返信メール本文の先頭行
に入れることもできます.
========================================================

決裁を行うには、最後の文にあるように、Approved ヘッダをつけたりした
メールにして送信することもできますが、昨今のメーラーではこのように
直接メールヘッダを書き込むことはむしろ困難なので、
指定された Web ページ上から承認/拒否作業を行うことになるでしょう。

決裁用画面そのものは処理が終わると消えてしまうので今再現できませんが
(上をもう1度やればいいのだけど、メンドイ)、
「承認」とか「破棄」とかを適宜選択すればいいようになっています。
 # ただ、使い方がちょっとわかりにくいところもあったけど、今は省略。

管理者が承認したメールは、サイズオーバーとか非会員とかであっても、
ML に配送されます。もちろん破棄とかにすれば送られません。

なお、前便で述べた respond_to_post_requests を「はい」にしておけば、
この時点で発信者にも承認待ちであることを通知するメールが届きますが、
「はい」とするのがいいかどうかは場合によります。

=====
このような決裁を挟むことで、冒頭の選択肢 (B) の場合について、
配送を認める/認めないを管理者判断で決められます。

なお承認処理のページには、管理者ページの右上「他の管理項目」
の「未処理の申請の処理」から入ることができます。
未処理事項がなければ「保留中の申請はありません.」と表示されます。

現実問題としては、メールサイズだけでなく、添付ファイルの有無そのもの
で決裁が入れられればいいのですが、今のところうまくできていません。

ウィルスと添付ファイル除去

*** ウィルス(ワーム)メール ***

サイズ制限、むしろ添付ファイルの可否について、実は重大なポイントとなるのが
「ウィルス(ワーム)メール」です。
これは学内用 ML ではあまり問題にはなりませんが(とも言い切れないけど)、
学会 ML のように学外者主体の ML だとかなり深刻です。

大学のゲートウェイでウィルスチェックはかけてますし、
非会員投稿を認めない ML であれば、非会員アドレスからの投稿を
留め置けますが、会員アドレスを詐称したり、さらには会員自身のマシンが
感染したような場合、かつウィルスチェック未対応のウィルスの場合には、
ML にウィルスが進入してきます。
ウィルスそのものは検疫された場合でも、削除結果のメールそのものは
ML に流れたりします。

ウィルス(ワーム)はほとんどすべての場合、添付ファイルとして
送られてきますから、「添付ファイル禁止」設定であれば、
ウィルスそのもの、あるいは検疫済みメールなどが ML に流れることを
ほとんどシャットアウトできます。
 # 検疫済みの場合でも、メッセージ自体が添付ファイル形式であったり、
 # なんらかの(無害)な添付ファイルが残っていたりします。


*** 添付ファイル除去の部 ***

そこで「添付ファイル除去」のページです。
どうも期待する動作をしてくれないし、単純に「除去」とすると overkill
になりそうだし、きちんと設定しようとすると難しいしで、
どうしたもんかと思案中のところです。

期待としては、「添付ファイルを削除」(filter_contents) を「はい」
とした上で、末尾の「マッチしたときの動作」(filter_action) を
「リスト管理者に転送」とすれば、上記のサイズオーバーの場合のように、
管理者決裁になってくれると思ったのですが、
そう設定してもうんともすんともいいません。

システム設定に問題があるのかもしれませんし、
こちらが誤解しているのかもしれません。

「除去」を「はい」にすると、
マッチした除去対象を削除したメールが配送されるのですが、
そのままだと発信者、さらに一般読者が見て何が送られてきたのか、
わからないでしょう。
そこで発信者はなんども同じものを送ろうとしだすかもしれません。

なお、除去対象(あるいは非除去対象)のファイルタイプをきちんと定義する、
例えば WORD ファイルは OK だが、gif, jpg 等の画像ファイルは除去、
といった設定をしようとすると、「MIME タイプ」についての知識が必要です。
これについては適宜検索などして調べてください。

このような状態ですので、現状では「添付ファイル除去」の使用は
お勧めできません。うまく使えれば(また機能すれば)有効だとは思うのですが。

======
というわけで、冒頭の選択肢について、(A)(添付ファイル無条件除去)は
現段階ではお勧めできません。
(B) と (C) は本質的には同じことで、管理業務としては、サイズオーバーの
場合の承認作業があります。

会員管理

ML 管理の中核とも言える会員管理についてです。
これは「プライバシー・オプション」の項目とも一部関連するので、
そちらにも言及します。

会員管理の内容は次の3つに分類できます。
 (A) 入会登録
 (B) 退会処理
 (C) 既登録者の設定変更
またそれぞれの処理の実行方法には次の3通りがあります。
 (1) 会員自身が行う
 (2) 会員用機能を利用して管理者が行う
 (3) 管理者権限で直接行う(「まとめて」処理)
(1), (2) は本質的には同じことで、(2) は管理者が(たとえ会員の
パスワードそのものは知らなくても)管理者パスワードで個人会員
ページに入れることなどを利用する形態です。
 # 余談ですが、一般会員が管理者と同じパスワードを(偶然)
 # 設定したら、管理者に何か警告でも来るかと試してみたのですが、
 # これは何も来ませんでした。

Mailman では fml に比べて、会員個人による情報アクセスや設定変更が
かなり自由にできるようになっています。しかし現実問題として、
そのようなアクセスを行う会員はほとんどいませんし、あるとしても
内容が限定されます(予想されるのは、保存書庫へのアクセス等)。
逆にあまりおおっぴらに個人アクセスについて広報すると、
使い方などの問い合わせが管理者に多数寄せられることも懸念されます。
したがって、会員のアクセスについては、必要最小限の範囲に
とどめようとは思っています。これについては「会員アクセスの制限」
の項で述べます。

なお個人会員からのアクセス方法は、Web の個人ページからの他に、
ML-request へのコマンドメール発送という方法もありますが、
こちらについては詳しく調べていないので、ここでは言及しません。
また管理用コマンドをメールで送信することはできず、Web の
管理ページからだけです。

===============================================================
*** 入会/退会の通知 ***

入会/退会にあたっては、管理者への通知と、対象となる個人会員への
通知(welcome/goodbye message)があります。
これらを行う/行わないの基本的な設定は、「全体的オプション」の
以下の項目で設定します([mailman-ml 042] も参照)。
 send_welcome_msg (会員への入会通知)
 send_goodbye_msg (会員への退会通知)
 admin_notify_mchanges (管理者への入会/退会通知)

上記 (1), (2) の方法での入退会の場合、この設定にしたがって通知の
有無が決まります。
また (3) の場合でも、「会員管理...」→「会員リスト」で、「退会」欄
をチェックすることで退会処理を行う場合でも同様です。
 # またおそらく、「配送エラー」による自動退会の場合でも同じでしょう。

一方、(3) の「会員管理...」→「まとめて入会登録」、「まとめて退会処理」
においては、上記の通知項目の有無を、ラジオボタンでその場で設定できます。
(初期設定は上記の「全体的オプション」のものがとられます。)
これは当該処理、つまり「変更を通信する」のボタンを押したときの
処理だけに有効な設定で、ここでの設定により「全体的オプション」での設定
が変わることはありません。

したがってデフォールトの設定は「全体的オプション」ページでしておき、
個別の処理で、違う設定を使いたい場合には「まとめて」ページの
ラジオボタンを使用してください。

なお、不通アドレスに対して退会処理を行う場合、そこに「退会通知」を
発送しても(不通アドレスなんだから)届かず、エラーメールになるだけ
ですので注意(実害はないとは言えるでしょうが)。

======
会員への入会通知(welcome message)は、
件名「"ML名" メーリングリスト へようこそ」というメールで、
「全体的オプション」で設定したメッセージの他に、
 ・メーリングリストアドレス
 ・メーリングリスト総合案内ページの URL
 ・個人設定ページの URL
 ・コマンドメールあて先アドレス(ML-request ...)
 ・個人設定ページのパスワード
が通知されます。

この実例は、mailman-ml への登録時に皆様にも送付されていると
思いますので、ここで掲げることは省略します。

一方、退会通知のほうは、「全体的オプション」で設定したメッセージが
送られるだけです。

===============================================================
(A) 新会員の入会登録

新しい会員の入会登録(正確には新規アドレス登録)は、
(1), (2) の方法としては、ML の総合案内ページの「ML の購読」から行います。

個人はこの方法しかありませんが、管理者がこれを使う(おそらく唯一の)
メリットは、パスワードをその場で自由に設定できる点にあります。
もっともそれほど重要とも思えませんが。

Mailman 自体は、原則として個人が入会申込みを行うことを禁止していません。
しかし無条件に登録されても当然困るので、「承認」等の手続きがあります。

この設定は、「プライバシーオプション」→「入会規則」のページで行います。
 # 「プライバシーオプション」をクリックするだけでこのページが開きます。

同ページ、最初の「広告しますか?」(advertised) は、詳しい説明がありませんが、
基本的には全 ML 一覧:
  https://mail.slis.tsukuba.ac.jp/mailman/listinfo
に掲載するかしないかの選択だと思います。
一般論として、ML の存在そのものは隠さないほうがいいでしょうから、
特殊な事情で存在そのものを隠したい場合を除いては「はい」(デフォールト)
でいいでしょう。

次の2つ: subscribe_policy, unsubscribe_policy が、入退会ポリシーです。
後者の退会のほうについては、デフォールト(推奨)通り「いいえ」でいいでしょう。
 # やめたい者を引き止める必要があるような特殊な場合を除いては。
 # 退会した事実自体は、管理者通知を設定しておけばわかる。

入会ポリシーのほうは:
 「確認」は入会申込者本人による確認
 「承認」は管理者による承認
の2点よりなります。

「確認」のほうは、email address に間違いがないか、また第3者が勝手に
登録したりしないかのチェック用でしょう。
登録自由のリスト(本サーバー上ではほとんどないものと思いますが)は、
「確認」だけの設定になります。

一方、「承認」は管理者による入会審査にあたります。
これを設定すると、入会承認の申請を求める次のようなメールが管理者に送られます。
=================================================================
以下のメーリングリストへの入会申請は、承認が必要です。

    申請者:	foo@slis.tsukuba.ac.jp
    リスト:	xxxxxx-ml@slis.tsukuba.ac.jp

適当な時に、以下のURLで承認作業をしてください。

	https://mail.slis.tsukuba.ac.jp/mailman/admindb/xxxxxx-ml
=================================================================
承認処理は上記ページで承認(あるいは拒否、etc.)を処理してください。

「確認+承認」がデフォールト設定ですが、この場合、申請者の確認を
得てから、承認を求める管理者宛メールが発送されます。
したがってこの段階で申請者側にグズグズされると、登録処理はそのまま
停滞します。

実際の運用では、確認済みの相手を登録するケースが多いでしょうから、
「確認」のステップは不要でしょう。
たとえ見ず知らずの申請者であっても、上記の「承認」メールで
アドレスはわかりますから、管理者が手動で問い合わせることはできます。

したがって私自身については、「確認+承認」ではなく、「承認」だけで
運用することになると思います。

======
(3) の管理者による入会登録は、「会員管理...」→「まとめて入会登録」
のページから行います。(「まとめて」といっても、もちろん1人単位での
登録をするのはかまいません。)

最初のチェック項目、「招待」というのは説明が見当たりませんが、
上記の「確認」と同じです。

通知項目については適宜チェックの上、アドレス入力画面です。

間に空白行があったり、前後に1バイト空白があるのはかまわないようです
(ちゃんとはじかれる)が、2バイト空白、というか全角文字一般はダメで、
エラーになります。
エラーの場合、エラー通知のメールは届きません。
が、「変更を送信」を押して表示されるページ(同じ「まとめて...」のページ)
の上端に:
 入会手続きのエラー:
  * でたらめ@slis.jp -- 危険なアドレス (規則外の文字)
のように、エラー表示がされます。これ、気づきにくいので注意。

このアドレス入力ではemail address だけでなく、氏名(オプション)も:

  山田太郎 <foo@slis.tsukuba.ac.jp>

のようにして入れられます。全角文字でも大丈夫のようです。
(氏名については下記参照)

この「まとめて」登録の場合、(「プライバシー...」の設定に関わらず)
承認処理は省略され、直ちに登録されます。
上記のように最初のチェック項目を「招待」とした場合には、
「確認」の場合と同様の確認要請メールが送られ、入会確認をすると
「承認」なしに登録されます。


なお、「まとめて入会登録」ではパスワード設定はできません。
この場合、システム側が付与したパスワードが自動設定されます。
(「案内ページ」からの登録で、パスワードを設定しなかった場合も同様)

====================
***** 氏名について *****

登録者の氏名は、必須ではありませんが、登録者の対応付けのためには
入れておいたほうがいいでしょう。
 # なお「会員名簿」には氏名は掲載されません。
学内教員ならアドレスだけで誰かはわかるかもしれませんが、
学生とか学外者だと、アドレスだけでは氏名はわからないですし。

それに関連しての注意を2つばかり。

・同一氏名に対し、複数アドレスを登録できます。
 これは同姓同名云々より、1人の人が複数のアドレスを ML 登録したい
 場合が問題で、「複数登録に支障なし」ということです。

・問題はその逆で、既登録アドレスを「まとめて入会」から改めて登録
 することはできません。(上記のように、ページ上部に
   入会手続きのエラー:
     * foo@slis.tsukuba.ac.jp -- 既に会員です
 のように出ます。)

 これの何が問題かというと、氏名をつけずに登録しておいたアドレス、
 あるいは間違った氏名の修正とかが、「まとめて」ページからは「できない」、
 ということです。

 もちろん、「会員リスト」ページで氏名入力・修正はできるのですが(後述)、
 個別の入力 and/or cut&paste になりますので、少人数ならともかく、
 大人数をこれでやるのは大変です。
 おそらく、一旦全員を「まとめて退会」し、氏名付きであらためて
 「まとめて入会」するのが現実的でしょう。

 というわけで、氏名の付与については(大人数 ML の場合ですが)、
 最初に全部入れてしまうか、氏名付与を断念するか、
 どっちかの選択が必要です。
  # fml では最初から氏名がついていないので、氏名-address 対応表を
  # 作るのはちょっと面倒だなあ。

これと少し関連するのですが、会員リストをテキスト形式で
入手することはできるのだろうか?(fml の members/actives に相当)
まあ、「会員リスト」をテキスト形式で出力、編集かしらん。

===============================================================
(B) 会員の退会処理

退会処理は、入会登録の裏返しとして、(1), (2) の方法、
(3) については「まとめて退会処理」のページからの方法で行えます。
これらの詳細は省略。

退会に関しては他に:
 ・「配送エラー処理」などによる自動退会
 ・「会員リスト」ページで、「退会」をクリックして「変更を通信する」
  を行う。
といった方法もあります。
後者があるので、「まとめて退会処理」はダブった機能とは言えます。
ただ、「まとめて退会」は通知オプションをその場で個別設定できるのに対し、
「会員リスト」ページの「退会」クリックでは「全体的オプション」の
設定が使われる(その場で個別設定できない)ことには注意。

===============================================================
(C) 既登録者の設定変更

これについても (1), (2) の場合は、個人会員ページから設定変更ができます。
こちらの設定が、(その会員については)ML 全体の設定に優先されます。

一方、(3) については「会員管理 ...」→「会員リスト」のページ
 # 「会員管理...」をクリックするだけで表示される
の会員リストの表での操作になります。
ただし、個人設定できるすべての項目がこの表にあるわけではありませんので、
それらをいじる場合には (2) の方法をとることになります。

(2) の場合もそうですが、(3)「会員リスト」においても、会員が設定した
内容を無断で変更すると怒られるかもしれないので注意。

「会員リスト」での表示・変更可能項目について、「退会」、「隠れ会員」
等はすでに説明したので省略。また後ろの「まとめ読み」以下も省略。
ここでの設定を行う場合、必要な項目の入力後、ページ下部にある
「変更を通信する」をクリックしてください。
 # 更新前設定の表示ページでうっかりクリックしないよう、要注意!!
 # 更新作業中は、「戻る」によっていったん「会員リスト」ページから
 # 出て、改めて再表示したりするのが確実です。

・会員氏名
 表示によってはテキストボックスがわかりにくいのですが、
 email address の下が氏名表示欄で、ここに氏名を入力/変更することができます。

・「制限」は read-only 会員の設定に相当。
 fml の members/actives の差分にあたります。
 アナウンス専用 ML でない限り、普通は使わないでしょう。

・「配送停止」は登録は残したままで、配送を一時停止する項目で、
 管理者ページでチェックを入れると「理由」として "[A]"(管理者がやった)
 が表示されます。

========
会員管理に関してはこんなところかな。

退会した会員についての記録は保存されないようで、「退会」→「再登録」しても
以前の情報は残らないようです。
 「配送エラー」→「自動退会」
になったりした場合などは少し問題なのですが。
ですから、一時的に所在不明とかいった場合には、「退会」ではなく、
「配送停止」にして登録は残しておいたほうがよさそうです。


会員がいろいろできるというのは一見よさそうではあるのですが、
現実問題としては、実際に使われる項目というのはそんなにないでしょうし、
いろいろ弄り回されたり、問い合わせが殺到するというのも管理者としては
正直、剣呑です。

入会・退会については直接管理者に申し込んでもらえばいいし、
 # 1日何百件もあるわけじゃなし
アドレス変更や配送停止等も同様。
パスワード変更も、そもそも設定機能を使わないなら不要。

.... と言いたいところなのですが、それでも利便性からどうしても
残りそうな用途として:
 ・保存書庫へのアクセス
 ・「話題」機能の利用(これはちょっと特殊かな?)
などがありえます。

保存書庫については、内容を一般公開して差し支えないなら
会員外にも公開しておけば、パスワードなしに入ることはできる。
 # Mailman そのものについての ML:
 # http://mm.tkikuchi.net/mailman/listinfo/mmjp-users
 # もそうですね

それでも、一部機能だけでも宣伝するのであれば、
丸ごと公開と同じことであり、伝えるだけは伝えて、後はご自由に、
といったことかしらん。

======
入会登録そのものの制限については、
機能そのものを殺すことはおそらくできないでしょうが、
「見えない」ようにすることはできる。

具体的には、「他の管理項目」→「公開 HTML ページを編集する」
で、「リスト総合案内ページ」の「ML の購読」の項目を消してしまう
(まあ、コメントアウトしてしまう)という方法です。
 # あれ?コメントとして残すと、実際に表示されるページにも
 # コメントとして残るのかな。
他のページ、例えば個人会員ページについても適宜編集をできますね。


「まとめて xxx」をした場合でも、管理者への通知は1件につき1通来ます。
つまり 300 件のデータ登録を「まとめて入会」で行えば、
管理者への入会通知が 300 通やってくる、というわけです。
「そんなもんほしくねえ」という人は(私もほしくないですが)、
「入会を管理者に通知する」のオプションを「いいえ」にした上で、
登録を実行してください。
 # 一括登録してるんだから、通知も一括送信してくれればいいのに。

なお、大人数を「まとめて」で登録し、welcome message を発送する設定に
しておくと、メール配送にかなりの時間がかかる可能性があります。
 # こればかりは実際に試してないのでやってみないとわかりません。
 # また実際にはバックグラウンドで実行され、Web ページのほうは
 # すぐ応答が返ってくるかもしれません。(登録処理そのものは、
 # 少々の人数でもそんなに時間はかからないと思います。)

なかなか応答が返ってこない場合でも、辛抱強く待ってみてください。

繰り返しになりますが、作業の各時点において、「画面の再読み込み」
([最新の画面に更新」)をコマメに行ってください。
本番の登録処理では、今のようなテスト中ほどには頻繁に画面を行ったり来たり
はしないかもしれませんが、それでも現在表示されている画面の内容が
最新の情報かはすぐわからなくなってしまいますので。

メールにヘッダやフッタをつける

・「普通配送オプション」
 これはメールに付けるヘッダ・フッタの問題です。
 デフォールトではヘッダは空、フッタにリストアドレス・URL などが入っています。

 しかしフッタが別パート扱いで全体が multipart/mixed になること、
 逆にヘッダ・フッタが空なら、本文が text/plain の場合、全体もそうなること、
 上記のデフォールト設定の内容はメールヘッダの List-* にも提示されており、
 全メールにわざわざ添付するほどのないこと、といった理由により、
 特に必要がない限り、ヘッダ・フッタとも空にしておくのが推奨です。
 # デフォールトでも空に設定されています
 
 空でない設定になっているものを空にする場合、空白、タブ、改行などの
 見えない文字が残ってないかを十分確認してください。
 (一番確実なのは、ページソースを見て、入力ウィンドウの HTML タグが:
   のように空っぽになっているかを見ることです。)

会員名簿

・「会員名簿の公開」
 (「プライバシーオプション」のトップページ:「入会規則」の一番下)

 「閲覧できる人」(private_roster) のデフォールトは「リスト会員」、
 つまり外部非公開ですが、まず「誰でも」(=外部にも公開)はよほど
 特殊な場合を除いて絶対ダメ、その上で、閲覧者は「リスト管理者のみ」
 (=要するに非公開)とすべきでしょう。理由としては:
  ・個人情報についての一般的な配慮、の他に、
  ・アドレスしか掲載されず、氏名が掲載されない。
   学外者中心のリストなどでは、アドレスだけでは誰のことかわからない。
  ・会員個人が「非公開(=隠れ会員)」を設定可能であり、
   多数の会員が非公開に設定すれば、名簿としての意味をなさない。
   連絡先など、必要なアドレスは別途公開すればよい。
 といったところです。

 その下、obscure_addresses は適用範囲からしてよくわからなくて、
 名簿のところだけなのか、保存書庫など、他の箇所にも及ぶのか(どうも
 及ばないようですが)からして不明。
 アドレスについては、"@" をそのまま出したり、"--at--" としたり、
 倍角の "@" 使ったり、"%40" のような HTML コーディング使ったりと様々です。

 なんですが、はっきり言って有効性ははなはだ疑問です。
 ちょっと賢い Crawler/Robot なら、この程度のことは対応してしまっている
 でしょう。とりわけ Mailman は広範に使われているシステムですから、
 何をやってるかぐらいは世間周知でしょう。
 だから結論を言えば、「やったところでムダでは?」です。

スレッド

保存書庫は「スレッド順」という機能を持っていますし、メールリーダーでも
スレッド対応機能を備えたものが多くなっています。
スレッド(thread) とは、同一の話題についてのメール・記事をひとまとめに、
さらには階層的にまとめたもので、多数の投稿があるメーリングリストや
ニュースグループ、掲示板などでは、関連メールをまとめるのに(ある程度)
有効な方法になっています。

スレッドの構成法は様々で、例えば Subject の類似性を用いるようなものも
ありますが、基本的にはあるメッセージに対しての直接的な応答かどうかを
表す明示情報を使います。メールの場合、これは普通には In-Reply-To や
References といったフィールドにあたります。(フィールドの値は、
返信元のメールの Message-ID です。)
これらのフィールドは、メールに対して「返信」で応答することで自動設定
されます。

記事に対する応答、それに対する返答といった応答が続けば有効なスレッドが
構成される一方:
 ・「返答」で応答しながら全然別の話題を始める、さらに件名等も
  適切なものに変更しない。
   # これは宛先だけを拾うために「返信」を用いるような場合に生じる。
 ・逆に、前の記事に対する応答であるのに、In-Reply-To などが適切に
  設定されず、したがって同一スレッドに分類されない。
といったようなケースが多発すると、スレッド機能が役に立ちません。

で、ここから先は運用、とりわけ会員各自への呼びかけの問題になるのですが、
保存書庫等のスレッド機能を有効に活用するには、
上記の意味での適切な応答の仕方、さらには件名 (Subject) の付け方が
必要とあることを周知していくべきでしょう。
「件名」のほうは「話題」機能(もし使う/使えるのであれば)のほうに
関係してきます。

総合案内ページの編集

obscure_addresses のような機能は、会員名簿等における
個人アドレスの保護を気にしているようですが、その一方、
もっと重要なターゲットに対しては無頓着なようにも思えます。

「もっと重要なターゲット」というのはメーリングリスト
そのもののアドレスです。
具体的には、「リストの総合案内ページ」は、デフォールト設定では
メーリングリストアドレスが、ご丁寧にも mailto 付きで
素のままで表示されます:
  <A HREF="mailto:xxxxxx-ml@slis.tsukuba.ac.jp">
	xxxxxx-ml@slis.tsukuba.ac.jp</A>

この結果どうなるかというと、総合案内ページは Web-crawler 君にも
素通しですから、ここでアドレスを集められると、リスト宛に
(学内用であろうが学外用であろうが関わりなく)SPAM が大量に
やってくる可能性がある、ということです。
いったんアドレスをとられたらもうアウトです。

そういった意味も含めて、公開 HTML ページ、特に総合案内ページは、
ML の実情に合わせて適宜編集したほうがいいでしょう。
それには「公開 HTML ページを編集する」から、
「リスト総合案内ページ」、「入会の結果ページ」、
「各会員用のオプションページ」を適宜編集してくだい。
 # 後2者は直接アクセスできるわけではないので、
 # セキュリティ的な面での重要性は低くなります。

ただ、これらを編集するには HTML の基礎知識は必要ですし、
"<MM-List-Name>"のような「固有タグ」(?というか、マクロというか)
が多用されているので、少し手をつけにくいところがあります。
実際の表示ページのソースと比較しながら、<MM-...> などがどう展開
されるかを確認してください。
 # 当然、どこかに説明書はあるんだろうけど、調べてない。
いじる対象は自分のメーリングリストだけですから、<MM-...> など使わず、
もろにテキストで書いてしまってもかまわないでしょう。

また HTML ページをいじる場合、うっかり破壊すると取り返しが
つかなくなりますから、初期ページ、また作業の適当な段階で、
随時テキスト保存するなどを強く薦めます。

=====
なお、この編集画面で HTML のコメント: <!-- ... --> で
コメントアウトしたものは、そのまま実際のページソースに残ります。
しかもご丁寧に、マクロ展開(?)までされて。

====<例:編集画面の内容>==========================================
<!--
	  メーリングリストの全会員に送るメールは,
	  <A HREF="mailto:<MM-Posting-Addr>">
	  <MM-Posting-Addr></A>
          のアドレス宛に送信してください.
 -->
====<展開されたページソース>======================================
<!--
	  メーリングリストの全会員に送るメールは,
	  <A
	  HREF="mailto:xxxxxx-ml@slis.tsukuba.ac.jp">
	  xxxxxx-ml@slis.tsukuba.ac.jp</A>
          のアドレス宛に送信してください.
-->
==================================================================

だから、アドレス等を本当に隠すのであれば、コメントアウトではダメで、
アドレス(あるいはそれを生成するマクロ)そのものを削除する必要があります。

======
ついでに、ページ末尾の管理人のメールアドレスにしても:
   <a href="mailto:xxxxxx-ml-owner@slis.tsukuba.ac.jp">
   jsmith at slis.tsukuba.ac.jp</a>
のように、表示されるのは個人アドレス(@ は at に隠してはある)であるのに
対し、実際のリンク先は -owner のアドレスです。
なんでこんな妙ちきりんなことするんだろ?

============================
私自身の管理するリストについては:
 ・ML アドレスは特に必要性のある場合を除いて消す。
 ・closed list 運用なので、ユーザ登録(ML 購読)の機能・フォームも消す。
 ・会員名簿も非公開なので、それに関する部分も消す。
 ・個人ページへのガイドリンクは残す、もっと使いやすい形にする。
 ・管理人アドレスは -owner だけが表示・リンクされるようにする。
 ・必要な情報は適宜書く。
 ・個人オプションのページに、保存書庫へのリンクなどを追加。

また「プライバシー・オプション」→「広告する」(advertised) を
どうするかはちょっと悩ましいのですが、原則として「いいえ」にしておきたい。
 # そうすると「全メーリングリスト一覧」のページにメーリングリスト名が
 # 掲載されません。

といったつもりでいます。

非会員投稿不可の ML であれば、SPAM(やウィルス)が ML そのものに
流れるのは一応食い止められますが、自動破棄(ってできたっけ?)
するのでなければ、管理人による破棄処理が必要です。
それを1日に十何回も何十回もやるのはやでしょ?

図書館情報メディア研究科教育・研究支援委員会
システム管理グループ