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 のものとそうでないものがあります。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これらも二番目のルールで 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>.