7.17.2


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

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

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

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

4.1	自動登録の概要

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

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

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

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

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


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	自動登録を有効にする
7.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	登録するアドレスの範囲を制限する
../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 タイプについては 5.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)


4.7	自動登録のタイプ: subject

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

	$AUTO_REGISTRATION_TYPE = "subject";


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

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

4.8	自動登録のタイプ: body

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

	$AUTO_REGISTRATION_TYPE = "body";


	この場合メールの本文に
	○ 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 してもらうのがよいでしょう。

____________________________________________________________________________
____________________________________________________________________________

4.10	&Confirm internal hook functions

	$CONFIRM_REPLAY_TEXT_FUNCTION		for test
	$CONFIRM_REPLAY_SUBJECT_FUNCTION	for subject

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

3.2

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

[fml 3.0]

[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";

です。


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


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

fukachan@phys.titech.ac.jp	matome

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

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

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

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

../internals 5.0

4.17	$AUTO_REGISTRATION_HOOK

例:

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

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