mime component filter のルール構成法

fml 4.0 の content filter とは異なり、 fml8 の mime component filter は

text/plain 	permit
text/html	reject
*		permit
みたいな空白区切りのフォーマットで書きます。

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 vs last match ?

アクションには first match のものとそうでないものがある。reject は た いてい first match ですが、cutoff は first match ではないとおもわれま す。さて?

permit の意味

では、permit はどうでしょう?実のところ文脈依存と考えらますが、何が正 しいのかよくわかりません。たとえば、multipart のメールの中身が

text/plain + image/jpeg + text/html
のように3つの異なるタイプのパートからなる場合、どういうルールなら曖昧 さがないのだろうか?

結論をいえば、cutoff や reject を指定するタイプのルールしかうまく機能 しない、つまり「特定の○○を削除ないしは拒否する」ことならうまくできる といえそうです。ゆえにデフォルトは permit にするしかない。

『permit は「個別に許す」という意味である』説と、『permit は「メール全 体を許す」という意味である』説の両方があります。たとえば、

text/plain	*	permit
*		*	reject
は text/plain は許す、それ以外のいかなる型も許さない。 これは text/plain に曖昧さがないので OK でしょう。

一方、『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 命令は意味があるわけです。

以下、first match を前提に、事例を考えてみましょう。

ケーススタディ: デフォルトの挙動

暗黙のデフォルトルールは、他の header や text フィルタとの整合性を考え ると、「とりあえず通す」ですかね?

*		*	permit
これは content filter の「ルールをうまく書けない」という別の理由によっ ても支持されるでしょう。

なお、デフォルトの挙動を reject に変更するには * * reject を最後に付け 加えてください。

ケーススタディ: text/plain (全体)のみをゆるす

text/plain	*	permit
*		*	reject

ケーススタディ: text/plain があれば何でも許す

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 のみを通すルールだとおもいます。

ケーススタディ: text/html (全体) および text/html を含む multipart だけを拒否

text/html	*		reject
multipart/*	text/html	reject
*		*		permit

ケーススタディ: むずかしい例?

じゃ、これはどうよ?これは簡単なルールが書けない例でんな。

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 されてしまう。 だめじゃん。

ケーススタディ: 前の例のバリエーションで reject ではなく cutoff

前の例のバリエーションで 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
も通過しちゃいます。

ケーススタディ: 前の例で 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 だが、ルールのマッチする場所が異なります。

fml 8.0 (fml-devel) project homepage is www.fml.org/software/fml-devel/.
fml 4.0 project homepage is www.fml.org/fml/menu.ja.html.
about one floppy bsd routers, see www.bsdrouter.org/.
other free softwares are found at www.fml.org/software/.

author's homepage is www.fml.org/home/fukachan/.
Also, visit nuinui's world :) at www.nuinui.net.

For questions about FML, e-mail <fml-bugs@fml.org>.