フィルタ: mime component filter のルール構成法

fml4 の content filter とは異なり、 fml8 の mime component filter のルールは

text/plain 	permit
text/html	reject
*		permit
のような空白区切りのフォーマットで書いてあります。

MIME が前提なので、!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
これらも二番目のルールで 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/fml8/.
fml 4.0 project homepage is www.fml.org/software/fml4/.
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>.