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のように３つの異なるタイプのパートからなる場合、 どういうルールなら「あいまいさ」がないでしょうか？
結論をいえば、 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 * * reject「multipart の中身が text/plain からのみなるメールなら許す」 つまり、
text/plain + text/plain + text/plainは許可します。 しかしながら
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 ですが、ルールのマッチする場所が異なります。
Copyright (C) 1993-2022 Ken'ichi Fukamachi mail:< fukachan at fml.org >