[PREVIOUS CHAPTER] [NEXT CHAPTER]
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		MLのメンバーのみ
	moderator		モデレーターのみ (5.0)

   [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 はいずれの場合も管理者へメールでの報告はいきます。

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

	メンバーのみ(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	自動登録とアクセス制御
4.0

自動登録は

	"投稿がメンバーだけ"(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

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

	$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 で配送もコマンドも受け
付けます。

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

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

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

	$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	リモートで管理する際のアクセス制御
../remote_control 4.0../encryption 4.0
 
../utility_programs 6.17 SMTPでは所詮どうしようもないのでデフォールトではリモートでサーバを管理 するようにはなっていません。可能な限り避けるべきです。リモート管理より Secure Shell で makefml を起動させるような仕組みがあるとよいですね。 Email Address と秘密鍵の組合せ もしくは 公開鍵暗合によりアクセス制御を 行なっています。詳細は「リモート管理」の章を見てください。 ../remote_control 4.0 ../remote_control 4.0

II アドレスについて


[PREVIOUS CHAPTER]
 [NEXT CHAPTER]