From 148ad8dc0db2ce35fd740919b67d83b24af08aab Mon Sep 17 00:00:00 2001 From: fukachan Date: Sun, 13 Apr 2003 03:29:00 +0000 Subject: merge 01_RFC_FILTER.txt and update filter --- fml/doc/ja/01_RFC_FILTER.txt | 332 ------------------ fml/doc/ja/tutorial/book.sgml | 4 +- fml/doc/ja/tutorial/customize/filter.sgml | 12 + .../tutorial/customize/recipe.filter.notice.sgml | 54 +++ fml/doc/ja/tutorial/include/chapters.ent | 9 +- fml/doc/ja/tutorial/internals/filter.sgml | 388 +++++++++++++++++++++ 6 files changed, 465 insertions(+), 334 deletions(-) delete mode 100644 fml/doc/ja/01_RFC_FILTER.txt create mode 100644 fml/doc/ja/tutorial/customize/filter.sgml create mode 100644 fml/doc/ja/tutorial/customize/recipe.filter.notice.sgml create mode 100644 fml/doc/ja/tutorial/internals/filter.sgml diff --git a/fml/doc/ja/01_RFC_FILTER.txt b/fml/doc/ja/01_RFC_FILTER.txt deleted file mode 100644 index ccd90e47..00000000 --- a/fml/doc/ja/01_RFC_FILTER.txt +++ /dev/null @@ -1,332 +0,0 @@ -* fml-help によるアンケートのまとめ - -まとめると、いまの機能でいいわけだ。content filter の起源となった -cutoff の機能はもう不要なんだね。ということなんだとおもふ。 - - - Q: content filter ってどういう風に使ってますか？ - - A: 使う場合には、ほぼ (1) で決まり。 - - 規模とポリシー(きびしくできるか否かなど)によって (2)もアリかも。 - - メールの型を厳しくできないＭＬは、そもそも content filter を - on にしない(例えば社内ＭＬ？)。 - - パターン例: - - (1) text/plain と multipart の text/plain だけは通す - text/plain じゃないメールなんて○○ ML では不要 - だいたい virus つきかもしれないじゃん - - (2) multipart で text/plain 以外があるようなメールは拒否 - virus つきかもしれないじゃん - - (3) multipart の text/html 部分を削る - いわゆる html メール - ＃ついでに text/plain に戻す(やりすぎかも…)？ - - (4) multipart の image/* 部分だけを削る - 画像なんてＭＬに送るなよぉ - - (5) text/html のメールなんて spam に決まってるから捨てる - - TODO: 拡張機能？ - - Q: content-type が正しいかどうかを調べる - image/gif なら本当に gif ? - - A: ん〜全部は無理だなぁ。File::なんとかで、 - ファイルのタイプを識別するモジュールとかあれば OK なのかも - しれず(?) - - -* X-Sequence: fml-devel 252 - -フィルタ - - header - - body - non-mime - permit / reject (4.0 の content filter の !MIME) - - mime component filter - 4.0 の content filter - - text/plain filter - ja, en, ... (言語依存) - 非言語依存パート (M$ GUID scanner みたいな) - - 先頭部分の text/plain パートに対する - シンタックスチェック - -本当はこれ以外に、外部の virus scanner なりに飛ばす迂回路が必要だと思 -うんだけど、それは考えてない。 -＃ とりあえず、それは postfix でやってくれぃと - - -○ TODO - -まだ、text/plain 部分は言語依存パートになってない。 -だいたい言語依存とかいうなら virus checker を切り離せよ ＞ おれ - -など、てんこもりなので、text_plain_filter ってちょっと整理が大変だなと。 -それは一旦おいといて、とっとと content filter の構造を再構成しよう。 - - text/plain permit - text/html reject - * permit - -みたいなルールに従って判定をするように改造したいとおもいます。 - -○ content filter ルール・ファイルのフォーマット - -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 にするしか - ないんだともいえる。 - - 以下、first match を前提に、事例を考えてみよう。 - - Example[0]: 暗黙のデフォルトルールは、他の header や text フィルタと - の整合性を考えると、「とりあえず通す」だろうか？ - - * * permit - - これは content filter の「ルールをうまく書けない」という別の理 - 由によっても支持されるだろう。 - - なお、デフォルトの挙動を reject に変更するには * * reject を最 - 後に付け加えれば良いだけだ。 - - Example[1]: text/plain (全体)のみをゆるす - - text/plain * permit - * * reject - - Example[2]: 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 のみを通すルールだろう - - Example[3]: text/html (全体) および - text/html を含む multipart だけを拒否 - - text/html * reject - multipart/* text/html reject - * * permit - - - Example[4]: じゃ、これはどうよ？ - - ＊＊＊ これは簡単なルールが書けない例 ＊＊＊ - - 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 - - これらも 2 番めのルールで permit されてしまう。 - だめじゃん。 - - - Example[5]: 4 のバリエーションで 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 - - も通過しちゃいます。 - - - Example[6]: 5 のバリエーションで 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 だが、ルールのマッチする場所が異なる。 - - -[議論] - Q: permit の定義は？ - - A: 『permit は「個別に許す」という意味である』説 - - text/plain * permit - * * reject - - は、text/plain は許す、それ以外のいかなる型も許さない。 - これは text/plain に曖昧さがないので OK。 - - text/plain * permit - * * reject - - - A: 『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 命令は意味が - ある。 - - -[参考] 現在の変数体系 - -=head2 フィルタ - -use_article_filter = yes - - -article_filter_functions = article_header_filter - article_non_mime_filter - article_mime_component_filter - article_text_plain_filter - -=head2 ヘッダ情報ベースのフィルタ - -use_article_header_filter = yes - -article_header_filter_rules = check_message_id - permit - -=head2 MIME 情報ベースのフィルタ - -use_article_non_mime_filter = yes - -article_non_mime_filter_rules = permit - -use_article_mime_component_filter = yes - -article_mime_component_filter_rules = $fml_config_dir/mime_component_filter - -=head2 テキスト部分に対するフィルタ - -use_article_text_plain_filter = yes - -article_text_plain_filter_rules = reject_not_iso2022jp_japanese_string - reject_null_mail_body - reject_one_line_message - reject_old_fml_command_syntax - reject_invalid_fml_command_syntax - reject_japanese_command_syntax - reject_ms_guid - permit - ----- -$FML: 01_RFC_FILTER.txt,v 1.2 2002/10/21 07:48:29 fukachan Exp $ diff --git a/fml/doc/ja/tutorial/book.sgml b/fml/doc/ja/tutorial/book.sgml index df46d104..67be8270 100644 --- a/fml/doc/ja/tutorial/book.sgml +++ b/fml/doc/ja/tutorial/book.sgml @@ -2,7 +2,7 @@ This is an sgml using DocBook dtd. Use sgmltools version 2.0.x or above to generate various output formats. -$FML: book.sgml,v 1.53 2003/03/12 00:18:29 fukachan Exp $ +$FML: book.sgml,v 1.54 2003/04/12 15:20:01 fukachan Exp $ --> &chapter.threadtrack; @@ -137,6 +138,7 @@ $FML: book.sgml,v 1.53 2003/03/12 00:18:29 fukachan Exp $ &chapter.delivery; &chapter.digest; &chapter.message; + &chapter.filter; diff --git a/fml/doc/ja/tutorial/customize/filter.sgml b/fml/doc/ja/tutorial/customize/filter.sgml new file mode 100644 index 00000000..f1959088 --- /dev/null +++ b/fml/doc/ja/tutorial/customize/filter.sgml @@ -0,0 +1,12 @@ + + + + + フィルタ + + +&recipe.filter.notice.sgml; + + diff --git a/fml/doc/ja/tutorial/customize/recipe.filter.notice.sgml b/fml/doc/ja/tutorial/customize/recipe.filter.notice.sgml new file mode 100644 index 00000000..c4fdcf27 --- /dev/null +++ b/fml/doc/ja/tutorial/customize/recipe.filter.notice.sgml @@ -0,0 +1,54 @@ + + + + + + + +フィルタで弾いた時に、エラーメールをどこへ返す + + + + + + +デフォルトでは + +use_article_filter_reject_notice = yes +article_filter_reject_notice_recipient = admin + +となっている。 +つまり、エラーメールを返し、返す先はＭＬの管理者だ。 + + + + +返送する先を送信者( From: のアドレス )にするには + +article_filter_reject_notice_recipient = sender + +とする。 + + + + +ＭＬの管理者と送信者( From: のアドレス )の両方に返すには + +article_filter_reject_notice_recipient = admin sender + +とする。 + + + + +そもそもエラーメールを返さないようにするには、 + +use_article_filter_reject_notice = no + + + + + + diff --git a/fml/doc/ja/tutorial/include/chapters.ent b/fml/doc/ja/tutorial/include/chapters.ent index b25425ff..80b2ef6c 100644 --- a/fml/doc/ja/tutorial/include/chapters.ent +++ b/fml/doc/ja/tutorial/include/chapters.ent @@ -1,5 +1,5 @@ @@ -71,6 +71,12 @@ + + + + + + @@ -107,6 +113,7 @@ + diff --git a/fml/doc/ja/tutorial/internals/filter.sgml b/fml/doc/ja/tutorial/internals/filter.sgml new file mode 100644 index 00000000..8064c720 --- /dev/null +++ b/fml/doc/ja/tutorial/internals/filter.sgml @@ -0,0 +1,388 @@ + + + + + フィルタ + + + + + + フィルタの概要 + + + +フィルタには大きく分けて３種類あります。 +ヘッダ、 +メール本文、 +MIME 構造を元にしたフィルタ(mime component filter)です。 +メール本文に対するフィルタには MIME でないものをどうするか？ +text/plain に対してより厳しいシンタックスチェックを行なうフィルタも +あるので、大きく分けると４つといえるかも。 + +header + +body + non-mime + permit / reject (4.0 の content filter の !MIME) + + mime component filter + 4.0 の content filter + + text/plain filter + ja, en, ... (言語依存) + 非言語依存パート (M$ GUID scanner みたいな) + 先頭部分の text/plain パートに対する + シンタックスチェック + +本当はこれ以外に、外部の virus scanner なりに飛ばす迂回路が必要だと思 +うんだけど今はまだ考えてない。とりあえず、それは postfix でやってくだ +さい。 + + + + + + + + mime component filter のルール構成法 + + + +fml 4.0 の content filter とは異なり、 +&fmldevel; の 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 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 + +これらも 2 番めのルールで 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 だが、ルールのマッチする場所が異なる。 + + + + + + + + 議論: mime component filter に必要な機能とは？ + + + +以下は、fml-help ＭＬによるアンケートのまとめです。 + + + +結論を先に書くと、いまの機能でいいようだ。content filter の起源となっ +た cutoff の機能はもう不要みたい。 + + + +さて、content filter の使い方をいくつか考えてみよう。 + +(1) text/plain と multipart の text/plain だけは通す + text/plain じゃないメールなんて○○ ML では不要 + だいたい virus つきかもしれないじゃん + +(2) multipart で text/plain 以外があるようなメールは拒否 + virus つきかもしれないじゃん + +(3) multipart の text/html 部分を削る + いわゆる html メール + ＃ついでに text/plain に戻す(やりすぎかも…)？ + +(4) multipart の image/* 部分だけを削る + 画像なんてＭＬに送るなよぉ + +(5) text/html のメールなんて spam に決まってるから捨てる + +まとめると、通常は (1) でよいということに決まりのようだ。 +規模とポリシー(きびしくできるか否かなど)によって(2)もアリかもしれない。 +例えば社内ＭＬのようにメールの型を厳しくできないＭＬは、そもそも +mime component filter を on にしない。 + + + + + + -- cgit v1.2.1