NONE TITLE 4.html
Keywords: NONE TITLE,fml, flexible mailing list manager, not listserv style but fmlserv emulates listserv or majordomo style

[PREVIOUS CHAPTER] [NEXT CHAPTER]

4 設計指針に関するいくつかの考察…

    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.13
    ../filter 2.13

    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: == サーバが配送した時間

    Date: の付け方は $DATE_TYPE で変更できます。詳しくは ../header_rewrite 3.5。

    元々の理念は、サーバをどう考えるか？という観点で

    1	サーバが単にリレーしてるだけ (passive?)

    なのか

    2	サーバまでの通信路はＯＫでした、はい。
    	じゃ今からサーバ→メンバーへ配送するね(active?)

    最初のデザイン当時 2 を重視したと。で、Posted: がサーバまでの配送の最
    低限の pointer として残して、Date: にはサーバ→メンバー配送のための情
    報としてサーバの localtime() をつけたと。そんな歴史的背景がありますね
    ＃まぁ当時からUUCPは除いて大抵２つはほとんど同じだったですけどね

    Date: と Posted: の時間差でネットワークのDELAY情報が分かるのは副次的効
    果です。

    その他の副産物として時間順ソートをするだけでＭＬの記事を追うことができ
    ます。つまりサーバが受けとった順ですね。
    ＃配送は途中のパスすべてに依存するのでメールを出した元の時間が
    ＃情報の順番とは限らないからです。
    ＃ See fml-support's ML Count: 01816, 01821 for the discussion

    4.5	Received: を削る
    ../header_rewrite 3.4

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

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

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

[PREVIOUS CHAPTER] [NEXT CHAPTER]