ここではメールヘッダによる認証しか取り上げていませんが、 安全のため、もっと厳しい設定を検討してください。 たとえば、 そもそもインターネット側に SMTP インターフェイスがないようなサーバの設定、 およびサーバの設置場所の選定などを行なうべきです。 fml8 単体で処理できる PGP 認証 が理想ですが、 この場合、 メールマガジンの担当者に PGP/GPG を使える技術力が要求されます。 ここが PGP 話のネックです。 メールマガジンは 「投稿可能なメンバーリストをカスタマイズ」 することで行なえます。 $member_maps から $primary_member_map を抜き、 かわりにメールマガジンを送信可能なメンバーのリスト (ここでは $ml_home_dir/members-mailmag ファイルとしましょう)を $member_maps に追加します。 member_maps = $ml_home_dir/members-mailmag このファイルに、メールマガジンの投稿者のアドレスを書いて下さい。 なお subscribe コマンドの利用方法はデフォルトのままでかまいません。 fml 4.0 のように subscribe コマンドの仕方を変更するといったやり方で実装していません。 メンバーの認証方法を config.cf で細かくコントロールできるので、 それを使う方法が subscribe コマンドを変更するより簡単です。 というのは subscribe や unsubscribe コマンドは 「 $primary_member_map や $primary_recipient_map に対する変更を加える」という仕様だからです。 一方、 メンバー認証時の探索には member_maps や recipient_maps を使うのです。 なお、それぞれのデフォルト値は次のようになっています。 member_maps = $primary_member_map $admin_member_maps recipient_maps = $primary_recipient_map file:$ml_home_dir/actives $recipient_maps に actives ファイルが入っているのは互換性のためです (&fml8; では、actives ファイルを使いませんが、 &fml4; のディレクトリ構造そのままでも動作するようにするための互換性です)。 よって、 これらの値をうまく設定すれば、 こういった設定が容易という具合になっているわけです。 さて、上述の member_maps = $ml_home_dir/members-mailmag という設定をした場合、動作は次のようになります。 ユーザが subscribe すると、そのアドレスは recipients ファイル($primary_recipient_map) と members ファイル($primary_member_map)に追加されていきます。 認証は members-mailmag にたいして行なわれるので、 members ファイルは認証時の探索に使われません。 そのため、一般ユーザは投稿できません。 投稿可能なユーザは members-mailmag ファイルにあるアドレスのユーザだけです。 一方、 配送は recipients ファイル($primary_recipient_map)を元に、 subscribe したユーザ宛にたいして行なわれます。 この部分は普通のＭＬと一緒です。 このように map が細かく設定されていることを利用すれば、 メールマガジンが簡単に実装できます。 別解としては、逆の方法も可能です。 primary_member_map = $tmp_dir/members-dummy などと設定し、メンバーリストの新規分追加先を変更して闇に葬る案です。 members には投稿可能なアドレスだけを書きます。 このほうが &fml4; 風で分かりやすいでしょうか。 2004/06 後半以降: キューイングシステムの改変により 「わざとエラーにしてメールキューに落し、 メールの中身を確認してから flush する(配送する)」 技が可能になりました。 これにより、 (1) まず一度送信してキューに入れ、 (2) キューの中身を確認したのちに配送をはじめる、 ことが出来ます。 つまり間違った内容のメールを出す可能性が非常に低くなり得ます。 設定は次のようにしてください。 config.cf では、次のように存在しないポートでも指定しておきます。 smtp_servers = 無意味なトランスポート [例] smtp_servers = 127.0.0.1:2025 こうしておくと、 記事を投稿したさいには配送エラーになり、&fml8; のメールキューに落ちます。 メールの中身や配送先を間違えなかったと確信があり、 配送して良いと判断した場合、 正しいトランスポートを指定してキューをフラッシュしてください。 % fml -o smtp_servers=正しいトランスポート ＭＬ名 flushq [例] % fml -o smtp_servers=127.0.0.1:25 ＭＬ名 flushq ちなみに flush と flushq コマンドは同じ意味です。 flushq が打ちづらいので flush コマンドも作ってみました。 もっとも、毎回、いちいち、 これらのコマンド群を打ち込むのは面倒なので、 シェルスクリプトを作っておくと良いでしょう。 社内向けに、 ＭＬのキューファイルを WWW サーバで見せるようにしておき、 OK なら、 そのシェルスクリプトを CGI で実行可能にしておくという方法もよいでしょう。 生のキューファイル名が見えてしまって、？？？になるとは思いますが、 こんなシステムなら一瞬で作れますよね？ さらに 「配送 OK 」 を出すのが 「送信者と異なる人」 という運用にすれば、 より安全なメールマガジンの運用になるでしょう。 というのは、 送信者が自分で自分に OK を出すと、 内容の審査/検査が甘くなるからです。