NONE TITLE 4.html
Keywords: NONE TITLE,fml, flexible mailing list manager, not listserv style but fmlserv emulates listserv or majordomo style

[PREVIOUS CHAPTER] [NEXT CHAPTER]

4 自動登録

    6.16.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
    4.5

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

    応用としてＭＬから抜ける時に confirmation を求める設定もできます(デフォー
    ルトはそこまでしない)
    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	自動登録を有効にする
    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	登録するアドレスの範囲を制限する
    ../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を利用している。
    3.2

    3.2

    4.11	[fml 1.x, fml 2.x] 登録とメンバーチェックに使うファイルについて
    ../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	複数アドレスから投稿だが配送先は一つ(自動登録モード)
    ../internals 8.0

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

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

    という場合を考えて、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 をチェックする)
    ../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: を管理者宛にする

[PREVIOUS CHAPTER] [NEXT CHAPTER]