merge 01_RFC_FILTER.txt and update filter

6 files changed, 465 insertions, 334 deletions

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 $
 -->
 
 <!doctype book public "-//FML//DTD DocBook V3.1-Based Extension//EN" [
@@ -85,6 +85,7 @@ $FML: book.sgml,v 1.53 2003/03/12 00:18:29 fukachan Exp $
 	&chapter.customize.mlstyle;
 	&chapter.customize.header;
 	&chapter.customize.command;
+	&chapter.customize.filter;
 
 	<!-- スレッド追跡システム -->
 	&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;
         <!-- &chapter.replybyfml; -->
 
 	<!-- コマンド -->
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 @@
+<!--
+   $FML$
+-->
+
+<chapter>
+	<title>
+	フィルタ
+	</title>
+
+&recipe.filter.notice.sgml;
+
+</chapter>
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 @@
+<!--
+   $FML: @recipe_template,v 1.1 2003/01/07 11:39:13 fukachan Exp $
+-->
+
+
+<qandaentry>
+
+<question>
+<para>
+フィルタで弾いた時に、エラーメールをどこへ返す
+</para>
+</question>
+
+<answer>
+
+<para>
+デフォルトでは
+<screen>
+use_article_filter_reject_notice	=	yes
+article_filter_reject_notice_recipient	=	admin
+</screen>
+となっている。
+つまり、エラーメールを返し、返す先はＭＬの管理者だ。
+</para>
+
+
+<para>
+返送する先を送信者( From: のアドレス )にするには
+<screen>
+article_filter_reject_notice_recipient	=	sender
+</screen>
+とする。
+</para>
+
+
+<para>
+ＭＬの管理者と送信者( From: のアドレス )の両方に返すには
+<screen>
+article_filter_reject_notice_recipient	=	admin sender
+</screen>
+とする。
+</para>
+
+
+<para>
+そもそもエラーメールを返さないようにするには、
+<screen>
+use_article_filter_reject_notice	=	no
+</screen>
+</para>
+
+</answer>
+
+</qandaentry>
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 @@
 <!--
-	$FML: chapters.ent,v 1.67 2003/03/12 00:18:30 fukachan Exp $
+	$FML: chapters.ent,v 1.68 2003/04/12 15:20:02 fukachan Exp $
 -->
 
 <!entity versin "1.1">
@@ -71,6 +71,12 @@
 <!entity recipe.header.tag.uppercase SYSTEM "customize/recipe.header.tag.uppercase.sgml">
 <!entity recipe.header.tag.lowercase SYSTEM "customize/recipe.header.tag.lowercase.sgml">
 
+<!-- フィルタ -->
+<!entity chapter.customize.filter    SYSTEM "customize/filter.sgml">
+<!entity recipe.filter.notice.sgml   SYSTEM "customize/recipe.filter.notice.sgml.sgml">
+
+
+
 <!entity sect.usage.guide           SYSTEM "usage/guide.sgml">
 <!entity sect.usage.subscribe       SYSTEM "usage/subscribe.sgml">
 <!entity sect.usage.unsubscribe     SYSTEM "usage/unsubscribe.sgml">
@@ -107,6 +113,7 @@
 <!entity chapter.policy           SYSTEM "policy.sgml">
 
 <!entity chapter.filename         SYSTEM "internals/filename.sgml">
+<!entity chapter.filter           SYSTEM "internals/filter.sgml">
 
 
 <!-- 配送 -->
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 @@
+<!--
+   $FML$
+-->
+
+<chapter id="internals.filter">
+	<title>
+	フィルタ
+	</title>
+
+
+<sect1>
+	<title>
+	フィルタの概要
+	</title>
+
+<para>
+フィルタには大きく分けて３種類あります。
+ヘッダ、
+メール本文、
+MIME 構造を元にしたフィルタ(mime component filter)です。
+メール本文に対するフィルタには MIME でないものをどうするか？
+text/plain に対してより厳しいシンタックスチェックを行なうフィルタも
+あるので、大きく分けると４つといえるかも。
+<screen>
+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 パートに対する
+		シンタックスチェック
+</screen>
+本当はこれ以外に、外部の virus scanner なりに飛ばす迂回路が必要だと思
+うんだけど今はまだ考えてない。とりあえず、それは postfix でやってくだ
+さい。
+</para>
+
+</sect1>
+
+
+<sect1>
+	<title>
+	mime component filter のルール構成法
+	</title>
+
+<para>
+fml 4.0 の content filter とは異なり、
+&fmldevel; の mime component filter は
+<screen>
+text/plain 	permit
+text/html	reject
+*		permit
+</screen>
+みたいなフォーマットで書く。
+</para>
+
+<para>
+MIME が前提なので、!MIME なんてのはない。が、text/plain と 
+multipart/mixed 中の text/plain を区別するために、こういう書き方である
+必要があるとおもう。
+<screen>
+全体			部分		アクション
+----------------------------------------------
+text/plain 		*		permit
+multipart/mixed		text/plain	permit
+multipart/mixed		text/html	reject
+multipart/mixed		image/*		cutoff
+*			*		permit
+</screen>
+さらに、将来はこういうのもありか？
+<screen>
+text/plain 		:uuencoded:	cutoff
+text/plain 		:size>500k	cutoff
+</screen>
+</para>
+
+<para>
+ルールの構成上の問題点はいくつかある。
+</para>
+
+<sect2>
+	<title>
+	first match vs last match ?
+	</title>
+
+<para>
+アクションには first match のものとそうでないものがある。
+reject は first match だが、cutoff は first match ではない。
+</para>
+
+</sect2>
+
+
+<sect2>
+	<title>
+	permit の意味
+	</title>
+
+<para>
+では、permit はどうだろうか？実のところ、文脈依存と考えられるのだが、
+どうするとよいだろうか？たとえば、multipart のメールの中身が
+<screen>
+text/plain + image/jpeg + text/html
+</screen>
+のように３つの異なるタイプのパートからなる場合、どういうルールなら曖昧
+さがないだろうか？結論をいえば、cutoff や reject を指定するタイプのルー
+ルしかうまく機能しない、つまり「特定の○○を削除ないしは拒否する」こと
+ならうまくできるといえる。ゆえにデフォルトは permit にするしかないんだ
+ともいえる。
+</para>
+
+<para>
+『permit は「個別に許す」という意味である』説と、
+『permit は「メール全体を許す」という意味である』説の両方がある。
+たとえば、
+<screen>
+text/plain	*	permit
+*		*	reject
+</screen>
+は text/plain は許す、それ以外のいかなる型も許さない。
+これは text/plain に曖昧さがないので OK。
+</para>
+
+<para>
+一方、『permit は「メール全体を許す」という意味である』説だが、たとえ
+ば text/plain のメールだけを許したいとしよう。 直観的にはこう書くだろ
+う。
+<screen>
+text/plain	*	permit
+*		*	reject
+</screen>
+しかし、これは permit が即 OK の意味でないとすると
+<screen>		
+*	*	reject
+</screen>
+と一緒になってしまう。だから permit は"メール全体を OK としてルールと
+の照らし合わせ処理をそこで終りにする"という意味にしないといけない。
+よって、次のようなルールはありえない。
+<screen>
+text/plain 		*		permit
+multipart/mixed		text/plain	permit
+multipart/mixed		text/html	reject
+multipart/mixed		image/*		cutoff
+*			*		permit
+</screen>
+というのは、このルールは次のように書いても同じだからである。
+<screen>
+text/plain 		*		permit
+multipart/mixed		text/html	reject
+multipart/mixed		image/*		cutoff
+*			*		permit
+</screen>
+つまり permit 命令で処理が終ってしまうとすれば、multipart に対しては事
+実上使ってはいけないことになる。『デフォルトの処理』か『text/plain * 』
+のようなものに対してのみ permit 命令は意味がある。
+</para>
+
+<para>
+以下、first match を前提に、事例を考えてみよう。
+</para>
+
+</sect2>
+
+
+<sect2>
+	<title>
+	ケーススタディ: デフォルトの挙動
+	</title>
+
+<para>
+暗黙のデフォルトルールは、他の header や text フィルタとの整合性を考え
+ると、「とりあえず通す」だろうか？
+<screen>
+*		*	permit
+</screen>
+これは content filter の「ルールをうまく書けない」という別の理由によっ
+ても支持されるだろう。
+</para>
+
+<para>
+なお、デフォルトの挙動を reject に変更するには * * reject を最後に付け
+加えれば良いだけだ。
+</para>
+
+</sect2>
+
+
+<sect2>
+	<title>
+	ケーススタディ: text/plain (全体)のみをゆるす
+	</title>
+
+<para>
+<screen>
+text/plain	*	permit
+*		*	reject
+</screen>
+</para>
+
+</sect2>
+
+
+<sect2>
+	<title>
+	ケーススタディ: text/plain があれば何でも許す
+	</title>
+
+<para>
+text/plain があれば何でも許す。それ以外の型は拒否する。
+これは簡単なルールが書けない例だ。
+<screen>
+text/plain	*		permit
+multipart/*	text/plain	permit
+*		*		reject
+</screen>
+しかし、このルールでは
+<screen>
+text/plain + text/plain + text/plain
+</screen>
+でも、
+<screen>
+text/plain + text/plain + image/jpeg
+</screen>
+でもどっちも OK になってしまうのね。だめじゃん。
+もっとも not オペレータ(!)があれば、解決は可能だ。
+<screen>
+text/plain	*		permit
+multipart/*	!text/plain	reject
+multipart/*	text/plain	permit
+*		*		reject
+</screen>
+たぶん、これが期待される plain/text のみを通すルールだろう
+
+</sect2>
+
+
+<sect2>
+	<title>
+	ケーススタディ: 
+	text/html (全体) および text/html を含む multipart だけを拒否
+	</title>
+
+<para>
+<screen>
+text/html	*		reject
+multipart/*	text/html	reject
+*		*		permit
+</screen>
+</para>
+
+</sect2>
+
+
+<sect2>
+	<title>
+	ケーススタディ: むずかしい例？
+	</title>
+
+<para>
+じゃ、これはどうよ？これは簡単なルールが書けない例だな。
+<screen>
+text/plain	*		permit
+multipart/*	text/plain	permit
+multipart/*	*		reject
+*		*		reject
+</screen>
+multipart の中身が text/plain からのみなるメールなら許す。つまり、
+<screen>
+text/plain + text/plain + text/plain
+</screen>
+は、OK。でも、
+<screen>
+text/plain + text/plain + image/jpeg
+text/plain + image/jpeg + text/html
+</screen>
+これらも 2 番めのルールで permit されてしまう。
+だめじゃん。
+</para>
+
+</sect2>
+
+
+<sect2>
+	<title>
+	ケーススタディ: 前の例のバリエーションで reject ではなく cutoff
+	</title>
+
+<para> 
+前の例のバリエーションで reject ではなく cutoff。
+<screen>   
+text/plain	*		permit
+multipart/*	image/*		cutoff
+multipart/*	text/plain	permit
+*		*		reject
+</screen>
+つまり
+<screen>
+text/plain + text/plain + text/plain
+</screen>
+は、OK。一方、
+<screen>
+text/plain + text/plain + image/jpeg
+</screen>
+のメールは image/jpeg 部分を削って、3番めのルールで permit される。でも、
+<screen>
+text/plain + image/jpeg + text/html
+</screen>
+も通過しちゃいます。
+</para>
+
+</sect2>
+
+
+<sect2>
+	<title>
+	ケーススタディ: 前の例で cutoff + permit にすると？
+	</title>
+
+<para>
+<screen>
+text/plain	*		permit
+multipart/*	image/*		cutoff
+multipart/*	image/*		permit
+multipart/*	text/plain	permit
+*		*		reject
+</screen>
+なら、
+<screen>
+text/plain + text/plain + text/plain
+text/plain + text/plain + image/jpeg
+text/plain + text/plain + text/html
+</screen>
+みな OK だが、ルールのマッチする場所が異なる。
+</para>
+
+</sect1>
+
+
+<sect1>
+	<title>
+	議論: mime component filter に必要な機能とは？
+	</title>
+
+<para>
+以下は、fml-help ＭＬによるアンケートのまとめです。
+</para>
+
+<para>
+結論を先に書くと、いまの機能でいいようだ。content filter の起源となっ
+た cutoff の機能はもう不要みたい。
+</para>
+
+<para>
+さて、content filter の使い方をいくつか考えてみよう。
+<screen>
+(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 に決まってるから捨てる
+</screen>
+まとめると、通常は (1) でよいということに決まりのようだ。
+規模とポリシー(きびしくできるか否かなど)によって(2)もアリかもしれない。
+例えば社内ＭＬのようにメールの型を厳しくできないＭＬは、そもそも 
+mime component filter を on にしない。
+</para>
+
+</sect1>
+
+
+</chapter>