fml8 チュートリアル (バージョン 7.99.1-20180910)
Prev | Chapter 39. フィルタ | Next

# フィルタ: 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

のように３つの異なるタイプのパートからなる場合、 どういうルールなら「あいまいさ」がないでしょうか？

結論をいえば、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 ですが、ルールのマッチする場所が異なります。

Prev | Home | Next
フィルタ: コマンドメールへの制限 | Up | 議論: mime component filter に必要な機能とは？

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