4.1	From: はすべてを認めるべきだろうか？

現在は $REJECT_ADDR で定義されたアドレス群を From: に含むものはエラー
として管理者へフォワードされます。それは個人を代表しているとみなされな
いアドレスにたいしてです。というのはＭＬとは個人と個人を結び付けるもの
だと思われるからです。現在は

    $REJECT_ADDR  = 'root|postmaster|MAILER-DAEMON|msgs|nobody';
    $REJECT_ADDR .= '|majordomo|listserv|listproc';

のように設定されています。From:がこれらのアドレスだった場合管理者へフォ
ワードし伺いを立てます。そこから後はＭＬ管理者の判断でしょう。

この他にも uudecode や sysdiag(苦笑) のような attack で出てきそうなア
ドレスもありますが、まぁまず使ってないでしょう。果たしてこれは増やすべ
きなのか、減らすべきなのか？私見としては、もっと増やすべきではないだろ
うかと思うのですが…

正規表現でマッチした Email アドレスをはじく機能もあります。
$REJECT_ADDR_LIST 中に正規表現を定義します。デフォールトは(CF に合わせ
て) spamlist というファイルです。
../filter 2.14
../filter 2.14

4.2	ML無限ループのチェックメカニズム
7.7

デフォールトは $CHECK_MESSAGE_ID がセットされています。この時は
「Message-ID: フィールドはメールそれぞれについて時空全体で unique であ
る」という定義を利用したループチェックを行ないます。

これ以外にもチェックはしていますが、理論上はこの uniqueness がもっとも
美しいでしょうね。

4.3	newsyslog(8)

/usr/bin/newsyslog に対応するものとして、libnewsyslog.pl が実装されて
います。昔の /etc/daily 等では

	...
	rename log.0 log.1
	rename log log.0
	...

とやっていたログファイルの整理を行なうプログラムです。NetBSD では、も
ともと MITの Athena Project で作られたプログラムが使われています。
fml.pl がnewsyslog を使って処理するデフォールトのファイル群は
@NEWSYSLOG_FILES で次のファイルに定められています。

    @NEWSYSLOG_FILES = 
	("$MSEND_RC.bak", "$MEMBER_LIST.bak", "$ACTIVE_LIST.bak");

つまりまとめおくり、配送・認証リスト等の変更があった時にできるバックアッ
プファイルです。これは日曜の朝 msend.pl (まとめおくりのプログラム)が実
行しています。まとめ送りをしていないなら実行されません。
まとめ送りをしていないならなんらかの形で別途動かす必要があります。

また関数コール自体(&NewSyslog)の引数(配列)は整理したいファイル群です。
変数 $NEWSYSLOG_MAX は「整理するのは何個までか？」を決めます。デフォー
ルトは４で、つまり

	log.4 log.3 ... log.0 log 

まで順番にまわって保存・整理されます。@NEWSYSLOG_FILES のログファイル
は msend が日曜の朝 newsyslog をかけます。

4.4	Date: == サーバが配送した時間


4.5	Received: を削る
../header_rewrite 3.4

4.6	Return-Receipt-To: も削るべき

配送したメンバー全員からメールが返ってくるから削るです。

もちろん本来はヘッダの意味を考えてメールを書かない”そのメールを出した
人”が悪いのはいうまでもありまん。