memo on first match et.al.

1 files changed, 207 insertions, 4 deletions

diff --git a/fml/doc/ja/01_RFC_FILTER.txt b/fml/doc/ja/01_RFC_FILTER.txt
index 641f70b5..8f61b9bc 100644
--- a/fml/doc/ja/01_RFC_FILTER.txt
+++ b/fml/doc/ja/01_RFC_FILTER.txt
@@ -37,8 +37,213 @@ X-Sequence: fml-devel 252
 
 みたいなルールに従って判定をするように改造したいとおもいます。
 
+○ content filter ルール・ファイルのフォーマット
 
-○ [参考] 現在の変数体系
+MIME が前提なので、!MIME なんてのはない。が、text/plain と 
+multipart/mixed 中の text/plain を区別するために、こういう書き方である
+必要があるとおもう。
+
+	例：
+		全体			部分		アクション
+		----------------------------------------------
+		text/plain 		*		permit
+		multipart/mixed		text/plain	permit
+		multipart/mixed		text/html	reject
+		multipart/mixed		image/*		cutoff
+		*			*		permit
+
+	さらに、将来はこういうのもありか？
+
+		text/plain 		:uuencoded:	cutoff
+		text/plain 		:size>500k	cutoff
+
+   問題点：
+	アクションには first match のものとそうでないものがある。
+	reject は first match だが、cutoff は first match ではない。
+
+	は、permit はどうだろうか？実のところ、文脈依存と考えられるの
+	だが、どうするとよいだろうか？たとえば、multipart のメールの中
+	身が
+
+		text/plain + image/jpeg + text/html
+
+	のように３つの異なるタイプのパートからなる場合、どういう
+	ルールなら曖昧さがないだろうか？
+
+	結論をいえば、cutoff や reject を指定するタイプのルールしかう
+	まく機能しない、つまり「特定の○○を削除ないしは拒否する」こと
+	ならうまくできるといえる。ゆえにデフォルトは permit にするしか
+	ないんだともいえる。
+
+	以下、first match を前提に、事例を考えてみよう。
+
+    Example[0]: 暗黙のデフォルトルールは、他の header や text フィルタと
+		の整合性を考えると、「とりあえず通す」だろうか？
+
+	*		*	permit
+
+	これは content filter の「ルールをうまく書けない」という別の理
+	由によっても支持されるだろう。
+
+	なお、デフォルトの挙動を reject に変更するには * * reject を最
+	後に付け加えれば良いだけだ。
+
+    Example[1]: text/plain (全体)のみをゆるす
+
+	text/plain	*	permit
+	*		*	reject
+
+    Example[2]: text/plain があれば何でも許す。
+		それ以外の型は拒否
+
+	＊＊＊ これは簡単なルールが書けない例 ＊＊＊
+
+	text/plain	*		permit
+	multipart/*	text/plain	permit
+	*		*		reject
+
+	しかし、このルールでは
+
+	text/plain + text/plain + text/plain
+
+	でも、
+
+	text/plain + text/plain + image/jpeg
+
+	でもどっちも OK になってしまうのね。
+	だめじゃん。
+
+	もっとも not オペレータ(!)があれば、解決は可能だ。
+
+	text/plain	*		permit
+	multipart/*	!text/plain	reject
+	multipart/*	text/plain	permit
+	*		*		reject
+
+	たぶん、これが期待される plain/text のみを通すルールだろう
+
+    Example[3]: text/html (全体) および
+		text/html を含む multipart だけを拒否
+
+	text/html	*		reject
+	multipart/*	text/html	reject
+	*		*		permit
+
+
+    Example[4]: じゃ、これはどうよ？
+   
+	＊＊＊ これは簡単なルールが書けない例 ＊＊＊
+
+	text/plain	*		permit
+	multipart/*	text/plain	permit
+	multipart/*	*		reject
+	*		*		reject
+
+	multipart の中身が text/plain からのみ
+	なるメールなら許す。つまり、
+
+	text/plain + text/plain + text/plain
+
+	は、OK。でも、
+
+	text/plain + text/plain + image/jpeg
+	text/plain + image/jpeg + text/html
+
+	これらも 2 番めのルールで permit されてしまう。
+	だめじゃん。
+
+
+    Example[5]: 4 のバリエーションで reject ではなく cutoff。
+   
+	text/plain	*		permit
+	multipart/*	image/*		cutoff
+	multipart/*	text/plain	permit
+	*		*		reject
+
+	text/plain + text/plain + text/plain
+
+	は、OK。一方、
+
+	text/plain + text/plain + image/jpeg
+
+	のメールは image/jpeg 部分を削って、3番めのルールで permit
+	される。でも、
+
+	text/plain + image/jpeg + text/html
+
+	も通過しちゃいます。
+
+
+    Example[6]: 5 のバリエーションで cutoff + permit すると？
+
+	text/plain	*		permit
+	multipart/*	image/*		cutoff
+	multipart/*	image/*		permit
+	multipart/*	text/plain	permit
+	*		*		reject
+
+	なら、
+
+	text/plain + text/plain + text/plain
+	text/plain + text/plain + image/jpeg
+	text/plain + text/plain + text/html
+
+	みな OK だが、ルールのマッチする場所が異なる。
+
+
+[議論]
+    Q: permit の定義は？
+
+    A: 『permit は「個別に許す」という意味である』説
+
+		text/plain	*	permit
+		*		*	reject
+
+	は、text/plain は許す、それ以外のいかなる型も許さない。
+	これは text/plain に曖昧さがないので OK。
+
+		text/plain	*	permit
+		*		*	reject
+
+
+    A: 『permit は「メール全体を許す」という意味である』説
+
+	たとえば text/plain のメールだけを許したいとしよう。 直観的に
+	はこうかくだろう。
+
+		text/plain	*	permit
+		*		*	reject
+
+	しかし、これは permit が即 OK の意味でないとすると
+		
+		*	*	reject
+
+	と一緒になってしまう。だから permit は"メール全体を OK として
+	ルールとの照らし合わせ処理をそこで終りにする"という意味にしな
+	いといけない。
+
+	よって、次のようなルールはありえない。
+
+		text/plain 		*		permit
+		multipart/mixed		text/plain	permit
+		multipart/mixed		text/html	reject
+		multipart/mixed		image/*		cutoff
+		*			*		permit
+
+	というのは、このルールは次のように書いても同じだからである。
+
+		text/plain 		*		permit
+		multipart/mixed		text/html	reject
+		multipart/mixed		image/*		cutoff
+		*			*		permit
+
+	つまり permit 命令で処理が終ってしまうとすれば、multipart に対
+	しては事実上使ってはいけないことになる。『デフォルトの処理』か
+	『text/plain * 』のようなものに対してのみ permit 命令は意味が
+	ある。
+
+
+[参考] 現在の変数体系
 
 =head2	フィルタ
 
@@ -80,7 +285,5 @@ article_text_plain_filter_rules	=	reject_not_iso2022jp_japanese_string
 					reject_ms_guid
 					permit
 
-
-
 ----
-$FML$
+$FML: 01_RFC_FILTER.txt,v 1.1 2002/10/03 15:30:55 fukachan Exp $