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 のものとそうでないものがある。reject は た いてい first match ですが、cutoff は first match ではないとおもわれま す。さて?
では、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 * permit * * reject
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 * reject multipart/* text/html reject * * permit
じゃ、これはどうよ?これは簡単なルールが書けない例でんな。
text/plain * permit multipart/* text/plain permit multipart/* * reject * * rejectmultipart の中身が 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。
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も通過しちゃいます。
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 だが、ルールのマッチする場所が異なります。
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>.