	メンバー登録や削除について

------------------------------------------------------------
I	登録について

1	概要
1.1	基本は手動登録
1.2	でも自動登録に設定することが多い
1.3	モデレータ: 誰でも投稿可だが、査読あり

2	Q & A
2.1	デフォールトの時に $MEMBER_LIST よりも $ADMIN_MEMBER_LIST が優先？

3	手動登録
3.1	subscribe コマンド(手動登録)時の挙動について(5 way hand shake)
3.2	ほんとに抜けるか？を確認する unsubscribe 
3.3	アドレスの変更 ("chaddr" command)

4	自動登録
4.1	自動登録の概要
4.2	自動登録を有効にする
4.3	登録するアドレスの範囲を制限する
4.4	ポストできる人は制限したいが、配送される人は自動登録したい場合
4.5	自動登録のタイプ
4.6	自動登録のタイプ: no-keyword
4.7	自動登録のタイプ: subject
4.8	自動登録のタイプ: body
4.9	自動登録のタイプ: confirmation (推奨)
4.10	&Confirm internal hook functions
4.11	[fml 1.x, fml 2.x] 登録とメンバーチェックに使うファイルについて
4.12	自動登録した際そのメールをフォワードするか否か？
4.13	メンバーチェックはしないけど自動登録はしたくない(+ trick)
4.14	複数アドレスから投稿だが配送先は一つ(自動登録モード)
4.15	サーバをインストールしたホストからのメンバーの自動登録ができない
4.16	自動登録の際の配送モード
4.17	$AUTO_REGISTRATION_HOOK

5	モデレータ
5.1	Overview
5.2	承認の仕方 ($MODERATOR_FORWARD_TYPE == 2 デフォールト)
5.3	承認の仕方 ($MODERATOR_FORWARD_TYPE == 1 もしくは 未定義)
5.4	承認の仕方 ($MODERATOR_FORWARD_TYPE == 3 もしくは 未定義)
5.5	メンバーを信頼度に応じて3段階に分ける
5.6	queueのexpire

6	配送とコマンド、そしてそのアクセス制御
6.1	アクセス制御のポリシー
6.2	自動登録とアクセス制御
6.3	配送用のアドレス ($MAIL_LIST)
6.4	コマンド専用のアドレス ($CONTROL_ADDRESS)
6.5	配送とコマンドを同じアドレスで行なう場合
6.6	コマンド or 特殊目的専用のサーバへの変更
6.7	リモートで管理する際のアクセス制御

II	アドレスについて

7	アドレス関係
7.1	コマンドコントロール専用のアドレス
7.2	メンバーチェックと自動登録について

III	事例集

8	いろいろ
8.1	From と 配送先が一致した時に、配送を止めたい(dynamical skip?)
8.2	off と skip
8.3	登録時の welcome メールが送り返されるのを止める
8.4	登録/削除以外は限りなく不必要
8.5	メーリングリストへの初投稿に至る手数をなるべく少なくしたい
8.6	skip コマンドの操作対象のファイルは？
8.7	メーリングリストに参加可能なユーザのドメインを絞る
8.8	『自動登録』かつ『ポストできる人を制限する』設定例その２
8.9	認証する際のドメインのALIAS %DOMAIN_ALIASES
8.10	メンバーチェックの際のアドレスのチェックの厳しさ
8.11	$MAINTAINER というアドレス
8.12	アドレスを組織ごとに管理したい
8.13	意見受付用アドレス？
8.14	複数アドレスから投稿したいがうけとりは一つ( "skip" コマンド)
8.15	ML-request をコマンド用のアドレスにする
------------------------------------------------------------


I	登録について
1	概要

まず basic_setup を見て欲しいです。

	../basic_setup/index.html

1.1	基本は手動登録

登録して欲しいというリクエストを受けたら、メールサーバ上で
makefml を使って登録作業をして下さい。詳細は 3 節

% makefml add elena アドレス

1.2	でも自動登録に設定することが多い

リクエストの数が多いと面倒ですからね:) 自動登録にするには

makefml config elena 

   MAIN MENU -> 1 -> WHEN_COMMAND_FROM_NOT_MEMBER -> auto_subscribe

を選ぶ。ユーザはメール本文に「subscribe 自分の名前(ローマ字)」と書いて
elena-ctl@ドメイン というアドレスへ出す。そうすると confirmation が返
るのでそれに答える。詳細は 4 節参照。

1.3	モデレータ: 誰でも投稿可だが、査読あり

誰でも投稿させると問題があるので査読をするという場合。これはモデレータ
と呼ばれています。詳細は 5 節

2	Q & A

2.1	デフォールトの時に $MEMBER_LIST よりも $ADMIN_MEMBER_LIST が優先？

そうです。まさに配送,認証リストが非対称でよかったねの例で、

1.  管理者がＭＬの記事自体は読んでない

2. でも「これメンバーでないからはじかれちゃったからＭＬへフォワード」
   とかはできないと困る

という意図の元にそういう風になっています。例:

	% makefml newml elena
	% makefml addadmin elena rudo@nuinui.fml.org

これしかしない状態ですね。記事は rudo には来ませんが、上の2の作業(ＭＬ
へのフォワード)はできます。

3	手動登録

○ 手動登録とは『fmlの動いているホストに入って、メンバーリストをいじる』
場合です。エディターないしmakefmlを使って行ないます。登録意志の確認を
fmlがしてくれることもありますが、最後のメンバーリストをいじる部分はＭ
Ｌ管理者が何らかの行動を起こす必要があります。

○ 自動登録とは『fmlが登録意志の確認から実際の登録作業』までを自動的に
行ないます。エラーの時だけが管理者の出番です。

○ 注意: 管理者がコマンドを送ってメンバーの登録を行なうやり方は手動登
録と呼んでいます。例: "admin subscribe fukachan@fml.org"

用語集 => Glossary 1.3
自動登録については次章の 4 を見て下さい。

3.1	subscribe コマンド(手動登録)時の挙動について(5 way hand shake)

*_*_HANDLER が auto_regist でない場合です。この時は管理者宛に登録依頼
メールをもらい、それをみて登録作業をします。ユーザーを登録するためには 
fml の動いているホストで makefml add を使ったり手でファイルを編集する
必要があります。

しかし、その登録依頼は他人のフリをしているのかもしれません。そのため登
録の前に本人かどうかの確認をするべきです。confirmation はこの確認作業
を fml が行なう場合です。forward_to_admin (元々の場合)で管理者がメール
を書いて正当性チェックをする場合のことをさしています。

	$MANUAL_REGISTRATION_TYPE ('confirmation' or 'forward_to_admin')

$MANUAL_REGISTRATION_TYPE は confirmation がデフォールトです。

手動で登録作業をするＭＬで、subscribe request をうけたらconfirm を返し、
confirm が帰ってきたら管理者は手で登録する。デフォールトは 
confirmation にしてある。＃ 2.2A

     ユーザ			fml			管理者

     1 ユーザがリクエストをfmlへ送る。
     subscribe request ->

     2 fmlは確認のメールを返す
     		<-  confirm req

     3 ユーザは確認のメールを返す
     confirm it       ->  

     4 fmlは確認したら、管理者に知らせる。
       ユーザにはちょっと待たれよとメールを送る

     		    confirm Okだったよん、いれてあげてぇ -> 管理者
     		<-
     confirmした
     管理者にしらせたからしばし待たれよ

     5 管理者が何らかの方法でユーザを加える。手で加えるなりコマンドなりで

     		admin add アドレス		<-
     		approve パスワード add アドレス

     (if $ADMIN_ADD_SEND_WELCOME_FILE == 1
     		<-
       welcome ♪のメール)

$MANUAL_REGISTRATION_CONFIRMATION_FILE というファイルがある時はこのファ
イルも送り返します。デフォールトではテンプレートを作ってありません。

	$MANUAL_REGISTRATION_CONFIRMATION_FILE (default $DIR/confirm.msub)

3.2	ほんとに抜けるか？を確認する unsubscribe 

自動登録には confirmation がありますが、その逆に抜ける時にも 
confirmation を求めるモードです。デフォールトではしません。
See also: 4.9 
See also: 4.9 

設定するためには

	$UNSUBSCRIBE_AUTH_TYPE = "confirmation";

とします。やり方は confirmation と同様です。「本当に抜けるのね？」と確
認を求めるメールが返るので、そのメールに reply してもらうと本当に抜け
ることができます。

3.3	アドレスの変更 ("chaddr" command)

ISPを変わった時、ドメイン名が変更になった場合などには新しいアドレスに
変更する必要があります。old-address を new-address へ変えるには

	1. chaddr コマンド
	2. 一回抜けてもう一度入る

の２つの方法があります。chaddrコマンドは

	chaddr old-address new-address

というシンタックスのコマンドです。

○ fml 2.2 の仕様, fml 2.2.1 の仕様 (default)
必ず『古いアドレスから』このコマンドを送ってください

	From: old-address
	To: list-ctl@domain

	chaddr old-address new-address

○ fml 2.2.1 のオプション  "chaddr confirmation"

chaddr を実行する前にconfirmationを行なうオプションがあります。

	$CHADDR_AUTH_TYPE = 'confirmation';

0. 	chaddrリクエストがfmlに来たら、それを行なっていいか？の確認の
	メールを送り返します。新旧両方のアドレスへ送ります。

1. 	新旧のアドレスのどちらか一方から chaddr を確認するメールがfml
	に届いたら chaddr 処理を実行以下の条件が必要です。

 1.1 コマンドを送ったメールのFrom: に設定したアドレスが、オプションに指
 　　定したアドレスのどちらかと一致する
 1.2 指定したアドレスのどちらかはすでにメンバー

2. 	結果にかかわらず、新旧両方のアドレスとＭＬサーバの管理者の３人に変
	更の通知がメールで送られます。
	＃ 管理者には届かないようにすることはできます。
	＃ @DenyProcedure('r2a#chaddr');

NOTE: 1999/10/04

	chaddr でサブドメインだけを変更しようとすると通常はエラーになる
	というのは変更先のアドレスがすでにメンバーリストにあるので。
	そのため

		chaddr foo@a.b.x.y.z foo@123.b.x.y.z

	のような時は、アドレスの似ている度合いを見て一時的に
	$ADDR_CHECK_MAX の値を上げることで正しく動作させる。
	これに伴い &SaveACL, &RetACL でこの関数呼び出しを
	保護する必要がある。HOOkなどで呼び出してる人は注意。

4	自動登録

See also: 6.1 6.2 

自動登録とは『fmlが登録意志の確認から実際の登録作業』までを自動的に行
ないます。エラーの時だけが管理者の出番です。
注意: 管理者がコマンドを送ってメンバーの登録を行なうやり方は手動登録と
呼んでいます。例: "admin subscribe fukachan@fml.org"

自動登録関連の設定は大きく

	自動登録をするか？しないか？
	$AUTO_REGISTRATION_TYPE  (タイプの選択)

の２つからなっています。以下では自動登録のがいようとタイプ/種類につい
て解説します。

4.1	自動登録の概要

fml は作った最初の時(1993)から

	デフォールトはメンバーのみがＭＬを使う
	手動で登録する

です。自動登録といった security を弱める方向へは明示的に設定をゆるめて
いく必要があります。変数名等もそういう概念を元にしています。

注意: 歴史的に『メンバーチェックをするという大前提』のため『メンバーチェッ
クなしにだれでもPOSTできる とか メールフォワード』にはならず、メンバー
チェックを切ったら メンバーでない人を自動的に登録するという動作になり
ます。

○ fml で "自動登録" は次の一連の動作のことです。

   1 あるアドレスについて、
   2 すでにＭＬのメンバーであるかどうかをチェックして
	$FILE_TO_REGIST (デフォールトは $MEMBER_LIST)
	の中のアドレスについてチェックします
   3 もしメンバーでないならそのアドレスをＭＬに登録する
	$FILE_TO_REGIST (デフォールトは $MEMBER_LIST)
	に登録します。
   4 登録した場合にはガイド等を送ってあげる

   また、管理者へ登録した旨をメールで知らせます。

この動作や登録メールに使うキーワード等は

	$AUTO_REGISTRATION_TYPE
See also: 4.5 

という変数で変わります。現在の推奨は confirmation というタイプです
＃confirmation タイプは 1997/02 以降のものに実装されています。
See also: 4.9 

応用としてＭＬから抜ける時に confirmation を求める設定もできます(デフォー
ルトはそこまでしない)
See also: 3.2 

confirmation はやや毛色が異なるので、ここではそれ以外の自動登録につい
て概要を解説します。

○ メンバーチェックおよび登録に使うアドレスは 
The target address to register is the address in From: or address in
subscription request (when $AUTO_REGISTRATION_TYPE is "subject" or
"body").

	From: にあるアドレス
or
	明示的にメールの本文中で指定されたもの

のいづれかです。RFC822的には Reply-To: があれば Reply-To: を使うべきだ
と思うのですが、危険なので使いません。それは、例えば Reply-To: ＭＬそ
れ自身をつけたまま登録要請をしてくる人が存在するために Reply-To: を信
じるのは危険すぎるためです。

また、それはユーザ用のメールインターフェイスの設定をなにげなしにうのみ
にしてしまうようなユーザ教育の敗因ともいえます。
”郵政省の郵便なら宛先、送り返して欲しい先を確かめないということがあり
うるでしょうか？…”

○ 自動登録で登録した際にはそのユーザーへガイド等を送り返します。

	$WELCOME_FILE	= "$DIR/guide";	# could be "$DIR/welcome"
	$WELCOME_STATEMENT = 
	"Welcome to our $ML_FN\n You are added automatically\n";

これらの変数が返送時のファイル($WELCOME_FILE)と そのメールの Subject
($WELCOME_STATEMENT)を決めています。

$WELCOME_FILE は送り返す歓迎の文章を書いたファイル (とりあえず、guide
にしておいてあります) で、また、そのメールの Subject が

	Subject: Welcome to our (Elena ML)
	 You are added automatically

のょうになります (since $ML_FN = "(Elena ML)")

4.2	自動登録を有効にする
See also: 6.1 

デフォールトのＭＬサーバの挙動は

   メンバーのみ(members_only)が投稿/コマンドの使用 が可能
   もしメンバー以外から来たら許否(reject)

です。自動登録は"投稿がメンバーだけ"(members_only)の場合に

   メンバー以外からメールが来た時は自動登録
   (→ auto_regist へ変更)

することで設定します(makefmlで制御できます)。config.ph 中では
(config.ph のデフォールト)

	$MAIL_LIST                     = "elena\@$DOMAINNAME";
	$PERMIT_POST_FROM              = "members_only";
	$REJECT_POST_HANDLER           = "reject";

	$CONTROL_ADDRESS               = "elena-ctl\@$DOMAINNAME";
	$PERMIT_COMMAND_FROM           = "members_only";
	$REJECT_COMMAND_HANDLER        = "reject";

の部分が

	$MAIL_LIST                     = "elena\@$DOMAINNAME";
	$PERMIT_POST_FROM              = "members_only";
	$REJECT_POST_HANDLER           = "reject";

	$CONTROL_ADDRESS               = "elena-ctl\@$DOMAINNAME";
	$PERMIT_COMMAND_FROM           = "members_only";
注意→	$REJECT_COMMAND_HANDLER        = "auto_regist";

のようになることです。この場合はメンバー以外の人が

	投稿した場合		→	許否(メンバーでないというメールが返る)

	コマンド用のアドレスへメール
				→	自動登録

のような動きをします。

	$REJECT_POST_HANDLER           = "auto_regist";

にすれば「投稿用のアドレスで自動登録」もできます。

4.3	登録するアドレスの範囲を制限する
See also: remote_control 4.14 

この変数は自動登録でもリモートコマンドによる登録でも制限できます。
しかし makefml では無効です。

デフォールトでは $REJECT_ADDR にあてはまらないならどんなアドレスでも登
録します。特定のドメインのみを登録対象にしたいなら 
$REGISTRATION_ACCEPT_ADDR に正規表現を書いて下さい。ある特定のドメイン
のユーザだけを登録の対象にする場合などに有効です。

Example 1; accept subscribe request from domain.co.jp
	$REGISTRATION_ACCEPT_ADDR = 'domain.co.jp';

Example 2;
	$REGISTRATION_ACCEPT_ADDR = 'domain1.co.jp|domain2.co.jp';

$AUTO_REGISTRATION_ACCEPT_ADDR は自動登録ルーチンにだけ作用する変数で
す。使用可能ですが obsolete です。

4.4	ポストできる人は制限したいが、配送される人は自動登録したい場合

$REJECT_COMMAND_HANDLER には特殊な auto_asymmetric_regist という値があ
ります。これは配送と認証のリストを非対称に使う時に使います。ただし 
elena-ctl を使うことを前提としています。

	elena/actives	MLの配送のリスト(自動登録に使う)
	elena/members	MLの認証に使うリスト(手動登録)
			(MLに投稿できる人のリスト)

4.5	自動登録のタイプ

自動登録のタイプ

	登録すべきアドレスをどこから選ぶか？
	登録アクションの起動にキーワード等を必要とするか？

により何種類も存在します。これは

	$AUTO_REGISTRATION_TYPE 

という変数で振舞いが変わります。この変数は

	confirmation
	body
	subject
	no-keyword

のうちの一つです。それぞれについて解説します。
confirmation タイプについては 4.9 参照。

4.6	自動登録のタイプ: no-keyword

『特別なキーワード等は必要としない。メンバー以外からメールが来たら自動
的に登録』です。

	$AUTO_REGISTRATION_TYPE = "no-keyword";

	From: からアドレスを割り出してそれを比較・登録に使います。
	"subscribe"で指定されるキーワードでメール本文に
	登録したいメールアドレスを指定することもできます。
	キーワードは

		subscribe your-mail-address 

	の形で使われます。このキーワードは変数

		$AUTO_REGISTRATION_KEYWORD

	で変更できます。
	(注:config.ph CFVersion 3 以前の $DEFAULT_SUBSCRIBE)

	From: をみてメンバーでない人からのメールだった場合は自動的に
	メンバーに加えます。

	From: と違うアドレスで登録したい時にこの方法で明示的に行なえます
	これから述べるキーワードを必要とする場合と違うのは 

		subscribe your-mail-address 

	のようなキーワードを含む書き方が"必須ではない"という点です。

	[歴史] この形式はもともとOFF会用MLなんかに便利です。
		例: 「出席します」メールがそのまま流れる。
		(こういう場合「出席します」以外のメールはほとんどない)

4.7	自動登録のタイプ: subject

『自動登録のためには Subject: にキーワードを必要とする場合』

	$AUTO_REGISTRATION_TYPE = "subject";

	(config.ph CFVersion 3 以前では
		$REQUIRE_SUBSCRIBE = "subscribe"; 
	に相当します)

	この場合メールヘッダの
	○ Subject: subscribe の時 From: のアドレス
	○ Subject: subscribe address なら、この address 
	をメンバーチェックおよび登録に使います。

	このいづれかのパターンにマッチしない場合は登録は行なわれず、
	登録の仕方が間違っているとユーザにメールが送られます。

4.8	自動登録のタイプ: body

『自動登録のためにはメール本文にキーワードを必要とする場合』

	$AUTO_REGISTRATION_TYPE = "body";

	(config.ph CFVersion 3 以前では
		$REQUIRE_SUBSCRIBE = "subscribe"; 
		$REQUIRE_SUBSCRIBE_IN_BODY = 1;
	に相当します)

	この場合メールの本文に
	○ subscribe の時は From: のアドレス
	○ subscribe address なら、この address 
	のいづれかをメンバーチェックおよび登録に使います。

	このいづれかのパターンにマッチしない場合は登録は行なわれず、
	登録の仕方が間違っているとユーザにメールが送られます。

4.9	自動登録のタイプ: confirmation (推奨)

	$AUTO_REGISTRATION_TYPE = "confirmation";

Confirmation (登録の確認) は自動登録をいきなりは行なわず、リクエストメー
ルに対し一旦「パスワードつきの確認メール」をリクエストメールの From: 
のアドレスへ返します。そして確認した旨のメールが返ってきてはじめて登録
を行ないます。処理の流れは次のようになります。

1	subscribe request

登録のリクエストメールでは心理的なファクターを考慮し、次のようなリクエ
ストを送ってもらいます。

	subscribe あなたの名前 (注意: Email Address ではなくあなたの名前)
	例：subscribe Ken'ichi Fukamachi 

のようなリクエストを送ってもらいます。$CONFIRMATION_SUBSCRIBE でこの 
subscribe というキーワードは変更できます。

2	reply from fml server

その一度めの登録リクエストに対し次のような行(この数字↓はあくまでも例
です)

	confirm 84682771 Ken'ichi Fukamachi

を含む reply が From: のアドレスに返ります。「このメーリングリストに登
録をしてもよいか？を確認するメール」です。これは「勝手にメーリングリス
トへ登録されてしまう」等のいたずらへの予防策です。
なおこのフレーズ"confirm 84682771 Ken'ichi Fukamachi"が含まれていれば
十分で行の先頭から始まっている必要はありません。つまり普通にREPLYして
引用の > などがついても問題はありません。

また reply にはこのモードの説明ドキュメント $CONFIRMATION_FILE
($DIR/confirm) が含まれて送られます。

3	confirmation 

あなたがこのメーリングリストへの参加確認のメールを受けとったなら、

	confirm パスワード(数字) あなたの名前

”この行だけ" を含むメールをもう一度登録用のアドレス 

	$CONFIRMATION_ADDRESS

へメールを返してもらいます。通常 $CONTROL_ADDRESS です(fmlserv か 
$MAIL_LIST かもしれませんが)。
＃ 例:
＃ $MAIL_LIST		elena@fml.org
＃ $CONTROL_ADDRESS	elena-ctl@fml.org

そうするとリクエストを出したユーザからの確認が得られたとみなし、サーバ
は From: のアドレスを登録します。なお "confirm" というキーワードは 
$CONFIRMATION_KEYWORD で変更できます。

[失敗した時最初からやり直したい場合]

	confirm パスワード(数字) あなたの名前

のメールをなくしてしまったとか、分からなくなってきたので最初からやりな
おしたいという場合は、”最初から”つまり

	subscribe Ken'ichi Fukamachi

を送ることからやり直してもらえばＯＫです。なお confirm reset
($CONFIRMATION_RESET_KEYWORDで設定) というコマンドで同じことができます
がまぁもう一度 subscribe してもらうのがよいでしょう。

____________________________________________________________________________
[confirmation のフロー]
ユーザ				ＭＬサーバ

subscribe	→		
				リクエスト受領
		←		「confirm パスワード(数字) あなたの名前」
				というメールを送って欲しいという返事

confirm パスワード あなたの名前
		→		
				「confirm パスワード あなたの名前」
				が正しいものなら登録

		←		登録しましたというメール
____________________________________________________________________________

4.10	&Confirm internal hook functions

	$CONFIRM_REPLAY_TEXT_FUNCTION		for test
	$CONFIRM_REPLAY_SUBJECT_FUNCTION	for subject

いろんな状態遷移に応じてsubjectやエラーの本文を作るための関数の名前。
unsubscribe confirmation はこのHOOKを利用している。
See also: 3.2 

See also: 3.2 

4.11	[fml 1.x, fml 2.x] 登録とメンバーチェックに使うファイルについて
See also: internals 8.4 

[fml 3.0]
fml 3.0 以降では自動登録か否かを問わず

		actives		配送リスト
		members		認証リスト

です。

[fml 1.x, 2.x]

自動登録の場合はactivesを使わずmembersファイルがmemberとactivesの両方
を兼任する形になっています。

	$FILE_TO_REGIST ($MEMBER_LIST in default)

に対して登録を行ないますが、メンバーチェックは

	@MEMBER_LIST

のファイル群に対して行ないます。これを利用するといろいろなことができる
はずです。

簡単な例： 実は fml.pl のデフォールトは

    @MEMBER_LIST = ($MEMBER_LIST, $ADMIN_MEMBER_LIST);

です。つまりリモートで管理する権限のある人をSETUPしたら、メンバーリス
トがなくてもリモートでＭＬのConfigができます。

また confirmation モードでのリクエスト要求の記録は

	$CONFIRMATION_LIST

というファイル(デフォールトは $DIR/var/log/confirm)に保存されています。

	$CONFIRMATION_EXPIRE

の時間(デフォールトは一週間)間に reply が返ってくれば有効です。

4.12	自動登録した際そのメールをフォワードするか否か？

「subscribe」としか本文にないメールをＭＬに流したくないので、自動登録
のデフォールトでは登録要請をしているそのメールをＭＬへ流さず管理者へそ
の旨を通知するだけです。
またフォワードは confirmation モードでは限りなく意味がありません:)

また自明ですがこの「フォワード処理をするか？否か？」は「どのアドレスを
登録に使うか？」の動作とは独立な設定です。

フォワードしたくないなら

	$AUTO_REGISTERED_UNDELIVER_P = 1;

そうでないなら 0 です。

しかしながら、流すという設定をしても、subscribe だけのメール (じつは8
行)は流しません。管理者以外は見てもうれしくないという配慮からです。
＃off 会用ならともかく『subscribe』と signature 4行くらいしかなかったり
＃するメールを流してもしょうがないです。

8 = 1 + 3行本文 + 4行シグニチャア ということで、デフォールトでは

	$AUTO_REGISTRATION_LINES_LIMIT = 8; 

のように定義されています。つまり 8 行を越えたメールはながれますが、そ
うでないとながれません。

これを -1 にしておけば、たとえ 中身の無いメールでも流れます;-)
＃注意： 0 だと、8 に変更されてしまう

なお、TYPOで $AUTO_REGISTERD_UNDELIVER_P になっている version が昔の 
fml にはありえます _o_

4.13	メンバーチェックはしないけど自動登録はしたくない(+ trick)

	$PERMIT_POST_FROM	= "anyone";

です(makefml config でも設定可能)。コマンドをだれにでも許すならさらに

	$PERMIT_COMMAND_FROM	= "anyone";

です。

[歴史]
+ trick は認証をしない、つまり誰でもＯＫという風にFMLに思わせる悪魔的
なやり方です。実装は members ($MEMBER_LIST) に

	+

と書いておくことで、、この行に出あった時点で認証されたとみなします。
＃シンタックスはNISにならっているです:-)

つまり + を書いてあると

	メンバーチェックするか否か？
	自動登録か？

に関わらずメールは配送されます。

この設定のデフォールトでは誰にでもコマンドが実行できるようにはしていま
せん。ＭＬのメンバーでない人に解放しているからといってコマンドも実行さ
せてよいとは限らないからです。

obsolete ですが昔は

    	$PROHIBIT_COMMAND_FOR_STRANGER = 1; (default)

という変数があって、0 にすれば + trick でもコマンドが使えるようになり
ました。つまり現在の 

	$PERMIT_COMMAND_FROM	= "anyone";

です。

4.14	複数アドレスから投稿だが配送先は一つ(自動登録モード)
See also: internals 8 

自動登録では見知らぬアドレスは全部新しい人とおもってしまうのですが、

	複数アドレスから投稿可能だが
	配送先ははある一つのアドレスに送って欲しい

という場合を考えて、members(自動登録では actives と兼任) で

	# fukachan@phys.titech.ac.jp
   および
	fukachan@phys.titech.ac.jp	skip

というシンタックスは fukachan@phys.titech.ac.jp をメンバーとして扱いま
すが、配送先にはしません。

つまり

	fukachan@phys.titech.ac.jp	skip
	Elena@phys.titech.ac.jp	
	# Pollyanna@phys.titech.ac.jp

という $MEMBER_LIST のファイルがあるとすると、fukachan, elena,
Pollyanna のどのアドレスからでも投稿はできるが、配送は elena にしか行
なわれないということになります。

なお、今の話とは無関係ですが 

fukachan@phys.titech.ac.jp	matome

の行も「まとめ送りの人だから」リアルタイムの配送の対象にはなりません。

4.15	サーバをインストールしたホストからのメンバーの自動登録ができない

この話は 
	user@domain 形式でないメールアドレスは登録の対象になるか？ 
という問題に還元されます。

RFC822 に従い user@domain 形式でないメールアドレスは ILLEGAL とみなす
べきです。つまりこれに対して何らかかの Operation を実行するのはよくな
いと考えるべきです。localhost の場合には認めるなどの条件をつけるならド
メインなしのアドレスも認めて良いと思いますが($PeerAddr をチェックする)
See also: internals 9.3 
See also: internals 9.3 

user@domain フォームでない ILLEGAL なメールアドレス が素通りして、サイ
トを越えて配送されてしまうようなこともありえます(設定次第)。よって変な
補整を加えてしまうとかえってまずいとおもいます。そういう場合こそ管理者
が吟味してＭＬやメールサーバの設定をメインテナンスするべきです。

それにもかかわらず自動的に登録するやり方としては次のようなものが考えら
れます。

○ sendmail.cf をいじる

これが一番まともな方法だと思うのですが、例えば Rule Set 10 で

R$+			$@$1<@$S>			user w/o host

で、user -> user@domain に変換する。
＃事前に DS$m されている（$m == domain です）

[sendmail.cf Example]

S10
R<@>			$n				errors to mailer-daemon

# append local address
R$*			$:$>11 $1

S11
R$*<@$*>$*		$@$1<@$2>$3			already qualified

# output local host as user@host.domain
R$=S			$@$1<@$j>			show exposed names
R$+			$@$1<@$S>			user w/o host

○ MHをいじる等のインターフェイスの制御でもOKですが、
   ただし、これはすべての場合にOKとは限らないやりかた

○ subscribe 形式の強制

“From行のアドレスに@以下をつけないでメールが送られてくる”

をやらせないために、ローカルドメインの人は 

	subscribe uja@localhost-name.uja.jp 

形式を必ず使ってもらう(confirmationではだめ)。

○ フックによる自動補正

自動補整も やってやれなくはないです。変なことがおきえますから、YOUR
OWN RISK でやってください

$START_HOOK  = q#
	if ($From_address !~ /\@/) {
		$From_address = "$From_address\@ローカルなドメイン";
	}
#;

ここでローカルなドメインは自分のドメインです。

4.16	自動登録の際の配送モード

メンバーファイルに書き込む時に

	アドレス $AUTO_REGISTRATION_DEFAULT_MODE

の形で行なう。fml の内部表現↑で設定する必要があるので注意して下さい。

例: デフォールトを skip にする

	$AUTO_REGISTRATION_DEFAULT_MODE	= "s=1"; 

    まとめおくりで３時間に一回 Multipart に設定。

	$AUTO_REGISTRATION_DEFAULT_MODE	= "m=3mp"; 

See also: internals 5 

4.17	$AUTO_REGISTRATION_HOOK

例:

$AUTO_REGISTRATION_HOOK = q#
    $e{'GH:Reply-To:'} = $MAINTAINER;
#;

WELCOMEのメールの Reply-To: を管理者宛にする

5	モデレータ

この章は『ＭＬに流す前に査読をする人がいるというシステム』についてです。

注: モデレータは moderator コマンドを使うためにＭＬのメンバーでないと
    だめです。members ないし members-admin にモデレータの人の
    アドレスを追加しておいて下さい。

5.1	Overview

モデレーター機能は、以下のような査読投稿システムです。

	1 ＭＬ宛に来たメールは配送されず
	2 一旦モデレーターへフォワードされます
	3 モデレーターは内容を査読後承認するなら
	  あるキーワード(パスワード)をＭＬサーバへ送ることで
	  ＭＬ全体へ配送されます。	
	 (このキーワードを送る方法については後述します)

変数は config.ph で

	$PERMIT_POST_FROM              = "moderator";

となっている状態です。makefml config の設定画面では

   [POST]

   1    PERMIT_POST_FROM                   moderators

のようになります。コマンドについても

   [COMMAND]

   3    PERMIT_COMMAND_FROM                moderators

設定はできますが、いちいち承認を出すコマンドというのは意味がない気がし
ます。が、実際にはコマンドへの承認をだすことができます:)

tricky なコードの副産物で $MAIL_LIST != $COMMAND_ADDRESS なのに
$MAIL_LIST も # moderator コマンドは理解してしまいます。このままでもい
いような気がしてそうなってます。$PERMIT_COMMAND_FROM が moderators は
tricky なことをしているので、ちょっとねぇ…

5.2	承認の仕方 ($MODERATOR_FORWARD_TYPE == 2 デフォールト)

$MODERATOR_FORWARD_TYPE という変数があります。デフォールトは２です。

次のようなメールがモデレーターに来ます。

   Moderated $MAIL_LIST (elena@fml.org) receives a submit from

      fukachan@fml.org.

   Please check it. If you certify the following article, 
   please send to elena-ctl@fml.org
   the following line (only this line!)

   moderator certified 199711032027.709982

   ------- Forwarded Message

   メール本文

   ------- End of Forwarded Message

メールはＭＬサーバも保存しています。メール本文の内容を承認したなら、

moderator certified 199711032027.709982

の行だけをコマンド用のアドレスに送って下さい。そうするとＭＬサーバは自
分が保存しておいたそのメールを配送します。

モデレーターか否かはこの特別な文字列(moderator certified 数字)を知っ
ているか否かです。この数字は毎回違うもるので、ある意味で暗合レベルの非
常に低い one time password だとみなすこともできます。

このメールが送られてくる人は誰でもモデレーターになれます。デフォールト
は $MAINTAINER ですが、複数の人をモデレーターにするなら moderators と
いうファイルを作り actives や members のように一行一アドレス書いていっ
て下さい。

5.3	承認の仕方 ($MODERATOR_FORWARD_TYPE == 1 もしくは 未定義)

承認を求めるメールがフォワードされるのは $MAINTAINER です。承認したか
否かはパスワード認証になります。パスワードを知っている人がモデレータと
いえます。ＭＬサーバへ送るメールのヘッダに Approval: line をつけて

	1 メールは一回管理者へフォワードされる。
        2 管理者が査読してOKとみなしたらＭＬへ投げる。
          Approval: password フィールドをヘッダにつけてＭＬに
          投げればメールは配送される。

パスワードはリモート管理のし方と同様に保守して下さい。
問題としては

	Approval: password をつかうのはいやだ
	＃こういう実装はいやなんだけど、してるだけ

	ださいMUA(メールユーザインターフェイス)がある

などがあるので回避策の一つとして

	admin forward
	フォワードする本文

というコマンドもあります。

	admin pass あなたのパスワード
	admin forward
	本文(この下は全部フォワードされる)

5.4	承認の仕方 ($MODERATOR_FORWARD_TYPE == 3 もしくは 未定義)
See also: 5.3 

Type III は I の変形です。パスワードを知っている人(モデレータ)は査読に
関わらず出せます。Approval: パスワード つきでメールをだせば査読にまわ
らずそのまま通過します。

See also "admin forward" command.
See also: 5.3 

5.5	メンバーを信頼度に応じて3段階に分ける

メンバーを3段階に分けることを考える。

group 1: モデレータ(の人々)。無条件に信頼される。
group 2: 信頼できるメンバ。普通に送ると普通に配送される。
group 3: 一般メンバ。普通に送るとモデレータに転送され、
	 通常のモデレータの手順を踏む。

通常モデレータモードは３段階ではないので改造が必要である。
ここではこれをHOOKでこれを実現することにする。

1. まずデフォールトはモデレータモードにする。makefml config なりcfに書
くなりして

	$PERMIT_POST_FROM  = "moderator";

になるようにする。

2. priv というファイルをＭＬのHOMEにつくり、group 2 に対応する信頼でき
るメンバー(だがモデレータではない)の群を登録する(一行一アドレス)。

3.  その上で以下のようなHOOKをcfの最後に入れて config.ph を再生成する。

$START_HOOK = q#
     $PRIV_LIST = "$DIR/priv";
      if (&CheckMember($From_address, $PRIV_LIST)) {
         $PERMIT_POST_FROM  = "members_only";
   }
#;

5.6	queueのexpire

	$MODERATOR_EXPIRE_LIMIT (default 14 == 2 weeks)

submitされたが承認されなかったメールは２週間(デフォールト値)たったら消
す。期間は $MODERATOR_EXPIRE_LIMIT という変数で制御する。

6	配送とコマンド、そしてそのアクセス制御

6.1	アクセス制御のポリシー

FML 2.1 (config.ph の CFVersion が 3)以降では 

	$PERMIT_POST_FROM
	$REJECT_POST_HANDLER
	$PERMIT_COMMAND_FROM
	$REJECT_COMMAND_HANDLER

という4つの変数がアクセス制御の鍵を握っています。また自動登録をするか
否か?もアクセス制御の一部としてこれらの変数で制御されます。それぞれの
意味は

   $PERMIT_POST_FROM		だれからの投稿を許すか?
   $REJECT_POST_HANDLER		メンバー以外からの投稿があったらどうするか?
   $PERMIT_COMMAND_FROM		だれからのコマンドを許すか?
   $REJECT_COMMAND_HANDLER	メンバー以外からのコマンドが来たらどうするか?

です。ありえる設定は

   [だれから？]
	anyone			だれでもOK
	members_only		ＭＬのメンバーのみ
	moderator		モデレーターのみ (5)

   [HANDLERの種類]
	reject			拒否 (deny というファイルが送り返される)
	auto_subscribe		自動登録 (fml Release 3)
	ignore			無視 

	(auto_regist		fml Release 2時代の自動登録)

例え anyone でも $REJECT_ADDR がその前に適用されることに注意して下さい。

    $REJECT_ADDR  = 'root|postmaster|MAILER-DAEMON|msgs|nobody';
    $REJECT_ADDR .= '|majordomo|listserv|listproc';

HANDLER はいずれの場合も管理者へメールでの報告はいきます。

デフォールトのＭＬサーバの挙動は

	メンバーのみ(members_only) 投稿/コマンドの使用 が可能
	もしメンバー以外から来たら許否(reject)

です。 config.ph のデフォールトは

	$MAIL_LIST                     = "elena\@$DOMAINNAME";
	$PERMIT_POST_FROM              = "members_only";
	$REJECT_POST_HANDLER           = "reject";

	$CONTROL_ADDRESS               = "elena-ctl\@$DOMAINNAME";
	$PERMIT_COMMAND_FROM           = "members_only";
	$REJECT_COMMAND_HANDLER        = "reject";

のようになっています(elena MLの場合)。

6.2	自動登録とアクセス制御
See also: 4 

自動登録は

	"投稿がメンバーだけ"(members_only)の場合に
	もしメンバー以外から来たら自動登録 → auto_subscribe へ変更

という設定をすることで行ないます(makefmlで制御できます)。config.ph 中
では

	$MAIL_LIST                     = "elena\@$DOMAINNAME";
	$PERMIT_POST_FROM              = "members_only";
	$REJECT_POST_HANDLER           = "reject";

	$CONTROL_ADDRESS               = "elena-ctl\@$DOMAINNAME";
	$PERMIT_COMMAND_FROM           = "members_only";
注意→	$REJECT_COMMAND_HANDLER        = "auto_subscribe";

のようになることです。この場合はメンバー以外の人が

	投稿した場合		→	許否(メンバーでないというメールが返る)

	コマンド用のアドレスへメール
				→	自動登録

のような動きをします。

	$REJECT_POST_HANDLER           = "auto_subscribe";

にすれば「投稿用のアドレスにメンバー以外からメールが来たら自動登録」に
することもできます。

6.3	配送用のアドレス ($MAIL_LIST)

$CFVersion 3 の config.ph では

   ・$MAIL_LIST と $CONTROL_ADDRESS が異なる場合(デフォールト)
	$MAIL_LIST は配送だけです。

   ・$MAIL_LIST と $CONTROL_ADDRESS が同じ場合
	$MAIL_LIST は配送もコマンドも受け付けます。
	"# command"を見つけるとコマンドモードになります。

投稿できる人の範囲(だれでも/メンバーだけ)は $PERMIT_POST_FROM で変更し
ます。デフォールトは members_only

どこかにＭＬがあってそれをフォワードするだけのアドレス/ＭＬ(再配送専用
のアドレス)を作る場合は

	$PERMIT_POST_FROM = "anyone";

とするべきです。

6.4	コマンド専用のアドレス ($CONTROL_ADDRESS)

makefml は listname-ctl というアドレスを用意します。$CONTROL_ADDRESS 
という変数がそれです。

これはコマンド専用です。listname-ctl 用に include-ctl というファイルを 
:include: するように設定されています。include-ctl では --ctladdr とい
うオプションがついているのがコマンド専用として fml.pl を起動するための
オプションです。このオプションを消さないで下さい。

コマンドを実行できる人の範囲(だれでも/メンバーだけ)は 
$PERMIT_COMMAND_FROM で変更します。特別な場合を除きこの変数を変えるこ
とはないでしょう。デフォールトは members_only

6.5	配送とコマンドを同じアドレスで行なう場合

2.1 RELEASE 以前の fml のデフォールトの挙動(Backward compatible)では 
サーバは一つのアドレスで配送もコマンドも受け持ちます。

2.1 RELEASE 以降では $CONTROL_ADDRESS と $MAIL_LIST を同じにすることで
実現することができますが makefml 等で明示的に設定変更が必要なことに注
意して下さい。

なお 2.1 RELEASE の config.ph は $CFVersion 3 です。以前の config.ph 
は 3 より小さい version か定義されていないかどちからです。3 より以前の
ものだと判断した場合は互換性のために $MAIL_LIST で配送もコマンドも受け
付けます。

配送とコマンドを同じアドレスで受けとる場合にはコマンドなのかどうか？を
判定する必要があります。判定基準は

	メールの最初の３行のどこかが 
	# command（英文字だけの塊）
	の場合コマンドモードへ移行する

です。ちなみにこの３行の３は

	$COMMAND_CHECK_LIMIT           = 3;

で決めています。

これは 配送するのか？コマンドを実行するのか？の切替の合図に 

	# command options

形を使っているからです。
＃Emacs の C- (control) とか vi のモード切替えみたいなものです:-)

コマンドしか受け付けないアドレスなら "# command" syntax じゃなくてもい
いはずでず…	

	$COMMAND_ONLY_SERVER           = 1;

とすると 

	# command options 

ではなくメールは

	command options

の形と仮定します。つまり通常のメールもすべてコマンドとみなされてしまう
コマンド専用のサーバになります。

6.6	コマンド or 特殊目的専用のサーバへの変更

コマンドについてはデフォールトで makefml が listname-ctl というコマン
ド専用のアドレスを用意します。それ以外にもある特定の目的専用のサーバを
作ることもできます。例えばftpmail や、info@domain.xx.jp として自動的に
組織の概要を送り返すサーバを作るなどが考えられます。

	$LOAD_LIBRARY = 'libfml.pl'; 

のように設定(default)したら コマンド専用だし、

	$LOAD_LIBRARY = 'libftpmail.pl'; 

とすれば ftpmail 専用のアドレスに早変わりです(注意: ftpmail 用の設定は
別途必要です)。

それは $LOAD_LIBRARY が設定されていると、そのライブラリを評価して実行
するように作動します。この場合配送は行なわれません。絶対配送させないよ
うにするために --ctladdr というコマンドラインオプションをつけておくと
よいでしょう。

6.7	リモートで管理する際のアクセス制御
See also: remote_control 4 encryption 4 utility_programs 6.17 

SMTPでは所詮どうしようもないのでデフォールトではリモートでサーバを管理
するようにはなっていません。可能な限り避けるべきです。リモート管理より
Secure Shell で makefml を起動させるような仕組みがあるとよいですね。

Email Address と秘密鍵の組合せ もしくは 公開鍵暗合によりアクセス制御を
行なっています。詳細は「リモート管理」の章を見てください。
See also: remote_control 4 
See also: remote_control 4 

II	アドレスについて
7	アドレス関係

7.1	コマンドコントロール専用のアドレス
See also: MTA Appendix B.1 

makefml が作るデフォールトの config.ph では

	$CONTROL_ADDRESS = "Elena-ctl\@$DOMAINNAME";

のように設定されています。
注意: この変数はFMLにどのアドレスを使っているかを知らせるためのもので
この変数がOSの挙動を変えているわけではありません。ヘッダなどの表示にも
使われています。

見本では コマンド専用の Elena-ctl アドレス宛のメールは include ではな
く include-ctl というファイルを :include: 構文で呼び出すように設定され
ています(include-ctl では fml.pl --ctladdr という形で呼び出す設定がさ
れているのが重要なポイントです)。

Elena-ctl宛のメールはコマンドのルーチンだけしか呼ばないようになります。
つまりこのアドレスにくれば間違ったシンタックスのメールがきても配送はし
ません。ちなみに

	'Elena-ctl';
	'Elena-ctl@axion.phys.titech.ac.jp';

どちらでもいいんですが、フルにアドレスを書く方が良いです。

最もローカルからコマンドメールを出す時のことを考えると、
フルアドレスじゃないほうが望ましいという意見もあります。
＃ sendmail.cf 等に依存した話なので断言はできませんが…

なお、この場合/etc/aliasesに

	Elena-ctl: :include:/var/spool/ml/elena/include-ctl

とか書いてあることが必要です。ちゃんと書いたかチェックと newaliasesも
忘れずに。makefml の指示通りにすればこの設定もしているはずですけど。

7.2	メンバーチェックと自動登録について
See also: 4 6 

設計思想としてＭＬサーバはあくまでプライベート・コミュニケイションの延
長であると考えています。デフォールトではサーバーはメンバーチェックを行
ないます。また、そういう意味で自動登録よりも管理者がチェックした後に手
で登録を行なうのがより良いといえるでしょう。それはまた security 上も望
ましいことです。
See also: 4 

"makefml newml" が終った状態つまりデフォールトの挙動では『メンバーとし
て登録されているアドレス』からのみ『投稿やコマンドメール』を送ることが
できます。

そうでない状態例えば自動登録などに設定を変更するなら"makefml config"を
使って設定を変更するないしcfやconfig.phを手で編集する必要があります。
自動登録は『メンバー以外からのメールが来た時に自動登録ルーチンを動かす』
という風に設定します。

メンバーのアクセス制御については Chapter 6.1 を参照し
て下さい。『メンバー以外からのメールが来た時に何をするか？』は

[$REJECT_COMMAND_HANDLER]

	$REJECT_COMMAND_HANDLER = "auto_regist"; (default "reject")

という変数で設定しています。

デフォールトは reject でメンバー以外の人がメールをＭＬに投げると『あん
たはメンバーでないからだめやねん』というメールを送り主に送り返します。
これを auto_regist に設定すると自動登録を行ないます。

自動登録は次のような設定が典型的です。

	$CONTROL_ADDRESS               = "elena-ctl\@$DOMAINNAME";
	$PERMIT_COMMAND_FROM           = "members_only";
	$REJECT_COMMAND_HANDLER        = "auto_regist";

「メンバー以外からのメールは拒否するが、その際自動登録処理」に入る。以
下いくつかの設定パターンについて考えます。

なお、昔は $ML_MEMBER_CHECK という変数で決めていましたが、今これは内部
変数として使われています。HOOK等で使われるだろうということを想定し歴史
的変数として残っています。$ML_MEMBER_CHECK が重要なのはこの変数によっ
て メンバーリストと配送リストが異なるからです。

[$PERMIT_POST_FROM    だれからの投稿を許すか？]
[$PERMIT_COMMAND_FROM だれからのコマンドメールを許すか？]

○ メンバーチェックについて

メンバーか否か？は $MEMBER_LIST (デフォールト members) の中に From: 行
のアドレスが存在するか否か？を調べています。

なお $REJECT_ADDR にマッチするアドレスはメンバーチェックに関わらず拒否
されます。例えば MAILER-DAEMON からのＭＬへの投稿などがそれに当てはま
ります。これはループなどの検出にも役に立ちます。

モデレータの場合はちょっと違うのでモデレータの章を参照 5。

○ 自動登録について

自動登録はキーワードを必要とするとか登録したいアドレスを指定したい時に
どうするか？等に関して様々なバリエーションがあります。
詳細については「自動登録」の章を見て下さい。
See also: 4 
See also: 4 

メンバーチェックは @MEMBER_LIST で定義されたファイル群の中に(デフォー
ルトでは $FILE_TO_REGIST, $MEMBER_LIST, そして $ADMIN_MEMBER_LIST)の中
に From: 行のアドレスが存在するか否か？を調べています。そこに存在しな
い場合は(例えば From: 行の)アドレスを自動的に $FILE_TO_REGIST
($MEMBER_LISTがデフォールト) に登録し管理者へその旨を知らせます。

配送は $MEMBER_LIST のみに従って配送されます(注意)。つまり自動登録時は 
$MEMBER_LIST しか使っていないのです。なお、このモードでは $ACTIVE_LIST
と $MEMBER_LIST は同じものに設定されています。

III	事例集
8	いろいろ

8.1	From と 配送先が一致した時に、配送を止めたい(dynamical skip?)

こういう処理を config.ph にかいてください。

$START_HOOK = q#
	$SKIP{'fukachan@phys.titech.ac.jp'} = 1
		if &AddressMatch($From_address, 'fukachan@phys.titech.ac.jp');
#;

こうすると fukachan@phys.titech.ac.jp あてのメールは skip します。
↑ここは actives とかに現れるものと同じにして下さい。

複数あるなら 全部を うえのフックに加えて下さい。

8.2	off と skip

fml-support: 07144

off はメンバ用
skip は管理者だけが使えるように

Count: 07122 で話題にあったように、エラー対策 (を兼ねたお知らせメイルな
んですが) として on off matome のメンバには定期的に個別にメイルを送って
ます。(skip の場合には送らないようにしている)

8.3	登録時の welcome メールが送り返されるのを止める

* fml 3.0 シリーズ

libamctl.pl というファイル（ 例: /usr/local/fml/libamctl.pl )に sub
AutoRegist ではじまる関数があって、その最後の方に

   &SendFile($from, $WELCOME_STATEMENT, $WELCOME_FILE);

というところがあります。ここを除いてもらうと絶対 welcome は送られませ
ん。次のような HOOK が 3.0 シリーズにはないので、トリッキーな回避の仕
方はないです。

* fml 4.0
    fml 4.0 では、非常にトリッキーなやりかたでよくありませんが、
    
    $AUTO_REGISTRATION_HOOK = q#
            sub SendFile {};
    #;
    
    という HOOK を書くと、welcome がおくられなくなります。

8.4	登録/削除以外は限りなく不必要

fml-support: 07271

条件1. 登録者に一切報告メール(welcome も)は送らない
条件2. 登録した、退会した、旨のメールのみ送る
条件3. よってコマンドは subscribe と bye 以外不要だろう
この３つの条件を実現するのは結構面倒です。

◯ welcome を送らない方法は前レシピも参照して下さい。

◯ 例えば、特定のコマンド( subscribe confirm bye )だけを許すには、次の
ようにします。これら３つがあれば登録削除だけができるはずです。

@PermitProcedure = ('subscribe', 'confirm', 'bye');

◯ 多くのコマンドは処理を終えるとリクエストを送ってきたユーザへ返事を
   返しますがそれを抑制するには

     &DEFINE_MODE('disablenotify');

をつかうこともできます。が、あまりにも抑制し過ぎてしまうので
かなり考え物です…

8.5	メーリングリストへの初投稿に至る手数をなるべく少なくしたい

fml-support: 07521 より

Q: メーリングリストへの初投稿に至る手数をなるべく少なくしたい

   A) メンバ以外のアドレスからML名@xxxxxxxxxx ($MAIL_LIST)
      へ投稿した場合は、
	[1] members ファイルに自動登録する。
	[2] 投稿されたメールをmembersに配送する。

	これだけですとメーリングリストへ参加するために何か投稿しなくて
	はならないので、コマンド用のアドレスでは登録のみを行うようにす
	る。即ち、

   B) メンバ以外のアドレスからML名-ctl@xxxxxxxxxx ($CONTROL_ADDRESS)
   へメールを送信した場合は、

	[1] membersに自動登録する。

A: config.ph でちょっと tricky だが 

    $AUTO_REGISTRATION_LINES_LIMIT = -1;
    $START_HOOK = q#
    	if ($Envelope{'mode:ctladdr'}) {
    		$AUTO_REGISTERED_UNDELIVER_P   = 1;
    	}
    	else {
    		$AUTO_REGISTERED_UNDELIVER_P   = 0;
    	}
    #;

のような設定をする。

8.6	skip コマンドの操作対象のファイルは？

fml-support: 07656, 07716

◯ list1 ,list2 というメーリングリストがあり、list1 の config.ph で
	push( @MEMBER_LIST, "$DIR/../list2/members" );
として list1,list2 は 包含関係にある。

◯ list1,list2 両方に 同じアドレスを登録してある人がいる。

どちらのＭＬのアドレスを操作しようとするか？

@MEMBER_LIST 配列の順にさがしていってそのアドレスが最初に見つかったファ
イルに対して操作を行ないます。

これは config.ph で定義した値は

  loading config.ph
  @MEMBER_LIST を再設定
  ...

の順で初期化をしているために list2 list1 の順でさがして list2 でみつかっ
て list2 のほうにそうさをしようとしてしまいます。

2.2A でなんとかするなら

$START_HOOK = q#
   push( @MEMBER_LIST, "$DIR/../list2/members" );
#;

8.7	メーリングリストに参加可能なユーザのドメインを絞る

自動登録やリモートでの登録の際の制限については 
$REGISTRATION_ACCEPT_ADDR という変数で制限できます。
See also: 4.3 remote_control 4.14 
See also: 4.3 remote_control 4.14 

直接そういう変数があるわけじゃないですが、特殊な処理をするために HOOK 
がいっぱいあります。ありうる可能性をすべて変数にしてるといくらあっても
追いつかないので

$START_HOOK = q#
   if ($From_address !~ /permit_domain\.co\.jp$/i) {
	&Mesg(*Envelope, 
	   "We permit user@*permit_domain.co.jp can join this list.");
	$DO_NOTHING = 1;
   }
#;

とかすれば、permit_domain.co.jp 以外のユーザには「permit_domainのゆー
ざだけしか参加できないよん」とメールが返って終りにできます。
$DO_NOTHING = 1 にすれば配送、自動登録などほとんど全ての処理が行なわれ
ません。これら全ての場合に共通の設定として利用できます。

	$DO_NOTHING = 1		メインの処理をしない
				配送、自動登録などほとんど全ての処理が
				行なわれないことになる

で、メインを呼ばなければ自動登録ルーチンも動きません。

   if ($From_address !~ /permit_domain\.co\.jp$/i) {

が From: が permit_domain 以外のユーザの表現です。後例えば

   if ($Envelope{'h:sender:'} !~ /permit_domain\.co\.jp/i) {

なら Sender: が permit_domain.co.jp 以外の人は参加できないことになりま
す。(が Sender: なんて From: == Sender: なら普通つけないからよくない例
だな)。

8.8	『自動登録』かつ『ポストできる人を制限する』設定例その２
See also: 4.4 

$REJECT_COMMAND_HANDLER には特殊な auto_asymmetric_regist という値があ
ります。これは配送と認証のリストを非対称に使う時に使います。
See also: 4.4 
See also: 4.4 

これは別の考え方です。elena と elena-regist という２つのＭＬを作る。

	elena		投稿専用(手動登録)
	elena-regist	コマンド専用(自動登録に設定しておく)

アドレスを書くファイル

	elena-regist/members	MLの配送のリスト(自動登録)
	elena/members		MLの認証に使うリスト(手動登録)
				(MLに投稿できる人のリスト)

という２つのＭＬを作り設定する。登録用に elena-registを作り elena/cf 
の ACTIVE_LIST を /var/spool/ml/elena-regist/members にする。

   [作業の流れ]

	% makefml newml elena
	% makefml newml elena-regist
	% cd /var/spool/ml/elena-regist
	% cp include-ctl include

	*** /etc/aliases を適宜設定する

	% cd /var/spool/ml/elena
	% makefml edit elena cf

	*** edit cf ふぁいる (ACTIVE_LISTを設定する)
	elena/cf に

	ACTIVE_LIST	/var/spool/ml/elena-regist/members

	を加え config.ph を再生成する。

	% make config.ph
	% makefml add elena postable-member-address-1
	% makefml add elena postable-member-address-2
	.....

[Discussion]
elena が elena-regist/members を open する時に elena-regist をロックし
てない。が、大丈夫だらう:)

8.9	認証する際のドメインのALIAS %DOMAIN_ALIASES

認証する時には ujauja.or.jp  => ujauja.ne.jp に書き換えてTRYしてみる

%DOMAIN_ALIASES = (
	'ujauja.or.jp', 'ujauja.ne.jp',
	);

＃ fml.pl 2.0.24.47 へのパッチの例

--- fml.pl.org	Fri Nov 21 08:11:10 1997
+++ fml.pl	Sat Nov 22 12:51:33 1997
@@ -571,6 +571,19 @@
     &Log("Gecos [$e{'macro:x'}]") if $debug;
     $e{'Addr2Reply:'}    = &Conv2mailbox($e{'h:reply-to:'},*e)||$From_address;

+    if (%DOMAIN_ALIASES) {
+       local($addr);
+	if (&MailListMemberP($From_address)) {
+	    ; # not rewrite
+	}
+	else {
+	    for (keys %DOMAIN_ALIASES) {
+		if ($From_address =~ /$_$/i) {
+                   $addr = $From_address;
+		    $addr =~ s/$_$/$DOMAIN_ALIASES{$_}/i;
+                   &MailListMemberP($addr) && ($From_address = $addr);
+		}
+	    }
+	}
+    }
+
     # To: $MAIL_LIST for readability;
     # &RewriteField(*e, 'Cc') unless $NOT_REWRITE_CC;
     if ($REWRITE_TO < 0) { 

8.10	メンバーチェックの際のアドレスのチェックの厳しさ

アドレスのチェックを緩めたりきつくしたりしたい場合は
See also: address_manipulate 2.1 

8.11	$MAINTAINER というアドレス

ＭＬの管理者のアドレスです。エラ−メ−ルの帰る場所もこのアドレスです。
$MAINTAINER と $MAIL_LIST が同じになっているとエラーメールがＭＬに返っ
てきて無限ループします。

インターネットでは歴史的に listname (MLの名前) に対して
『listname-request は管理者のアドレス』であることが多いです(絶対ではあ
りません)。ちょっと request というのが直感に反するところもありますが…
いつも僕はこの事実との整合性とわかりやすさのために

	listname-admin 		管理者のアドレス
	listname-request 	listname-adminへフォワード

のように設定しています。そのためどちらのアドレスへ送られても管理者へそ
のメールは届くわけです。makefml のデフォールトは listname-admin です。
プロバイダではそれぞれの設定があったりするので注意して下さい。

8.12	アドレスを組織ごとに管理したい

	A社	a.list
	B社	b.list
	C社	c.list

各社では自社のメンバーリストを管理する

A: config.ph に

	@MEMBER_LIST = (
			"$DIR/a.list",
			"$DIR/b.list",
			"$DIR/c.list",
			);
	@ACTIVE_LIST = (
			"$DIR/a.list",
			"$DIR/b.list",
			"$DIR/c.list",
			);

8.13	意見受付用アドレス？

意見受付用アドレスをMLでうけて、送ってきた人に「ご意見ありがとうござい
ました。返事はしばらく待ってね。」と自動で応答させる。

改造:
そのために投稿は誰でもOK。ただし、メンバー以外からの投稿はMLに流し、か
つ投稿者にguideファイルを返す（自動登録はしない）。

config.phの設定例 1:

    ### sample configuration ###
    $PERMIT_POST_FROM              = "anyone";
    
    # YOU CAN EDIT MANUALLY AFTER HERE.
    $START_HOOK = q# 
       if (! &MailListMemberP($From_address)) { &GuideRequest(*Envelope);} 
    #;

config.ph 設定例 2:
guide ではなくguideとは別に用意したファイルを返す。
ヘッダもカスタマイズ

From: $MAIL_LIST
Subject: Thanks you for your mail

    ### sample configuration ###
    $PERMIT_POST_FROM              = "anyone";
    
    # YOU CAN EDIT MANUALLY AFTER HERE.
    $RECRUIT_ACK_STATEMENT = "Thanks you for your mail";
    $RECRUIT_ACK_FILE      = "$DIR/recruit_reply";
    
    $START_HOOK = q#
        if (! &MailListMemberP($From_address)) {
    	&DEFINE_FIELD_OF_REPORT_MAIL('From', $MAIL_LIST);
            &SendFile($From_address, $RECRUIT_ACK_STATEMENT, $RECRUIT_ACK_FILE);
        }
    #;

8.14	複数アドレスから投稿したいがうけとりは一つ( "skip" コマンド)

複数アドレスから投稿可能だがうけとりはあるアドレスに送って欲しい、「こ
の１週間だけこのアドレスも使いたい」などの場合にも効果的です。これらの
場合を想定して actives(自動登録では members = actives) で

fukachan@phys.titech.ac.jp	skip

と書いておけば認証(新人さんチェック)には使うけど配送はしないという動作
をします。つまり

	fukachan@phys.titech.ac.jp	skip
	Elena@phys.titech.ac.jp	
	Pollyanna@phys.titech.ac.jp	skip

になっているとすると、fukachan,elena,pollyannaどこからでも投稿はできる
が、配送はelenaにしか行なわれないということです。

ユーザーがこれを自分でコントロールしたいなら、コマンドは
＃ Admin command でのみ引数が有効です。

skip	 [引数]		From:のアドレス もしあれば 引数のアドレスを
			そこから投稿はできるが、配送はされないものと設定する
noskip [引数]		上の逆。配送するようにする。

です。例：
skip 
	From: のアドレスを skip に

skip pollyanna@phys.titech.ac.jp
	pollyanna@phys.titech.ac.jp を skip に

noskip pollyanna@phys.titech.ac.jp
	pollyanna@phys.titech.ac.jp へも配送を

8.15	ML-request をコマンド用のアドレスにする

1 	-request 宛をコマンドにするためには、-request 宛が fml.pl を
     	呼ぶようにしなければなりません。つまり /etc/aliases を変更し
	listname-request がコマンド用の include-ctl を呼ぶようにしていないと
	いけません。例: elena ML の場合

	elena-request: :include:/var/spool/ml/elena/include-ctl

   ファイル include-ctl は

	"|/usr/local/fml/fml.pl /var/spool/ml/elena --ctladdr"

のようになっている必要があります。

2 	また配送するメールのヘッダではコマンドの送り先情報を
	書いています。ユーザの便宜のためアドレスも変えて下さい。
	config.ph  なら

	$CONTROL_ADDRESS       = "elena-request\@$DOMAINNAME";

と登録する必要があります。問題はこの場合 $MAINTAINER をどうするかです。-
request のままだとエラーの時恐いので、 elena-admin 等をつくってそれは
本当の単なる管理者宛のフォワード等にするとよいとおもいます。ちなみにデ
フォールトは elena-admin なのでそのままで大丈夫でしょう。

$Id: examples.wix,v 1.9 2001/02/01 15:11:31 fukachan Exp $


		INDEX

+ トリック                                 ...   4.13 
/etc/aliases ＋ アーカイブ                 ...   4.13 
$AUTO_REGISTERD_UNDELIVER_P                ...   4.12 
$AUTO_REGISTERED_UNDELIVER_P               ...   4.12 
$AUTO_REGISTRATION_DEFAULT_MODE            ...   4.16 
$AUTO_REGISTRATION_HOOK                    ...   4.17 
$AUTO_REGISTRATION_KEYWORD                 ...   4.6 
$AUTO_REGISTRATION_TYPE                    ...   4.5 
$AUTO_REGISTRATION_TYPE                    ...   4.6 
body                                       ...   4.5 
$COMMAND_CHECK_LIMIT                       ...   6.4 6.5 
&Confirm                                   ...   4.10 
$CONFIRM_REPLAY_SUBJECT_FUNCTION           ...   4.10 
$CONFIRM_REPLAY_TEXT_FUNCTION              ...   4.10 
confirmation                               ...   4.5 
$CONFIRMATION_ADDRESS                      ...   4.9 
$CONFIRMATION_EXPIRE                       ...   4.9 
$CONFIRMATION_FILE                         ...   4.9 
$CONFIRMATION_KEYWORD                      ...   4.9 
$CONFIRMATION_LIST                         ...   4.9 
$CONFIRMATION_RESET_KEYWORD                ...   4.9 
$CONFIRMATION_SUBSCRIBE                    ...   4.9 
confirmation mode                          ...   4.9 
$CONTROL_ADDRESS                           ...   7.1 8.15 
$DEFAULT_SUBSCRIBE                         ...   4.6 
distribute-only                            ...   6.3 
$FILE_TO_REGIST                            ...   4.1 
$MAIL_LIST                                 ...   6.3 
$MAINTAINER                                ...   8.11 
$MANUAL_REGISTRATION_CONFIRMATION_FILE     ...   3.1 
$MANUAL_REGISTRATION_TYPE                  ...   3.1 
$MEMBER_LIST                               ...   4.1 4.11 
@MEMBER_LIST                               ...   4.11 
$ML_MEMBER_CHECK                           ...   4.1 
ML-request をコマンド用のアドレスにする    ...   8.15 
no-keyword                                 ...   4.5 
noskip                                     ...   8.14 
$PERMIT_COMMAND_FROM                       ...   6.1 
$PERMIT_POST_FROM                          ...   6.1 
$PROHIBIT_COMMAND_FOR_STRANGER             ...   4.13 
$REGISTRATION_ACCEPT_ADDR                  ...   4.3 
$REJECT_COMMAND_HANDLER                    ...   6.1 
$REJECT_POST_HANDLER                       ...   6.1 
$REQUIRE_SUBSCRIBE                         ...   4.7 4.8 
$REQUIRE_SUBSCRIBE_IN_BODY                 ...   4.8 
s=skip                                     ...   4.14 
skip                                       ...   4.14 8.1 8.14 
%SKIP                                      ...   8.1 
$START_HOOK                                ...   8.1 
subject                                    ...   4.5 
UNIX_FROM                                  ...   8.11 
user@domain でないと自動登録できない       ...   4.15 
user@domain 形式でないメールアドレスは登録の対象になるか？   ...   4.15 
$WELCOME_FILE                              ...   4.1 
アドレス                                   ...   8.1 
コマンドの専用アドレス                     ...   7.1 
コマンド専用のサーバへの変更               ...   6.6 
サーバをインストールしたホストからのメンバーの自動登録ができない   ...   4.15 
再配送専用のアドレス                       ...   6.3 
自動登録: body                             ...   4.8 
自動登録: confirmation (推奨)              ...   4.9 
自動登録: no-keyword                       ...   4.6 
自動登録: subject                          ...   4.7 
自動登録: Subject にキーワードを宣言してもらう   ...   4.5 
自動登録: タイプ                           ...   4.5 
自動登録: メール本文にキーワードを宣言してもらう   ...   4.5 
自動登録: 登録に使うアドレス               ...   4.5 
自動登録: 方法のvariation                  ...   4.5 
自動登録のIntroduction                     ...   4.1 
特殊目的専用のサーバへの変更               ...   6.6 
配送用のアドレス ($MAIL_LIST)              ...   6.3 
複数アドレスから投稿だが配送先は一つ(自動登録モード)   ...   4.14 
