ここではメールヘッダによる認証しか取り上げていませんが、 安全のため、もっともっと厳しい設定をするべきです。 たとえば、そもそもインターネット側に SMTP インターフェイスがないような サーバの設定、およびサーバの設置場所の選定などを行なうべきです。 メールマガジンは投稿可能なメンバーリストをカスタマイズすることで行なえ ます。 member_maps から $primary_member_maps を抜き、 代わりに投稿可能なメンバーのリスト(ここでは $ml_home_dir/members-mailmag としましょう)を member_maps を追加します。 member_maps = $ml_home_dir/members-mailmag なお subscribe コマンドの利用方法はデフォルトのままで構いません。 fml 4.0 のように subscribe コマンドの仕方を変更するといったやり方 ではありません。 メンバーの認証方法を config.cf できめ細かくコントロールできるので、 それを使う方が、subscribe コマンドを変更するより簡単ですしね。 なお、この場合 subscribe したアドレスが members というファイルに追加されていきますが、 このファイルは使わないという設定なので大丈夫です。 気にはなるかも知れませんが… 別解としては、逆に primary_member_map = $tmp_dir/members-dummy などとメンバーリストの新規分追加先を変更して闇に葬り、 membersには投稿可能なアドレスだけを書くというやり方もあります。 このほうが &fml4; 風で分かりやすいでしょう。 2004/06 後半以降: キューイングシステムの改変により、「わざとエラーにし てメールキューに落し、メールの中身を確認してから flush する(配送する)」 なんて技もできるようになりました。 設定は次のようになります。 config.cf では、次のように存在しないポートでも指定しておきます。 smtp_servers = 無意味なトランスポート [例] smtp_servers = 127.0.0.1:2025 こうしておくと、 記事を投稿したさいには配送エラーになり、 メールキューに落ちます。 メールの中身や配送先を間違えなかったと確信があり、 配送して良いと判断した場合、 正しいトランスポートを指定してキューをフラッシュしてください。 % fml -o smtp_servers=正しいトランスポート ＭＬ名 flushq [例] % fml -o smtp_servers=127.0.0.1:25 ＭＬ名 flushq ちなみに flush と flushq コマンドは同じ意味です。 flushq が打ちづらいので flush コマンドも作ってみました。