ここではメールヘッダによる認証しか取り上げていませんが、 安全のため、もっと厳しい設定をしてください。 たとえば、そもそもインターネット側に 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 したユーザ宛にたいして行なわれます。 ここの部分は普通のＭＬと一緒です。 別解としては、逆の方法も可能です。 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 を出すと、検査が甘くなるからです。