fmlconf コマンドが各ＭＬの変数一覧を表示してくれます。 どのＭＬ(実のところ適当なＭＬでよい)を指定してかまいませんので、 fmlconf を実行して下さい。 たとえば

% /usr/local/bin/fmlconf test |grep fml_version
fml_version                          = fml-devel current-20021029

% postconf mail_version

% echo '$v' | sendmail -bt

答えは、たぶん 1.03 + よく分からないパッチ群です。 インストールした人なり、 使ったパッケージシステムの中をのぞきまくるかしてください。

一般論は存在しません。 DJB 教は「パッチをあてろ！」という運用を考えない文化なのでしょうがないです。

fmladdr コマンドが /etc/passwd で定義されているユーザと aliases ファイルに設定されている全アドレスを表示してくれます。

% /usr/local/bin/fmladdr

fmlalias コマンドが aliases ファイル(群)に設定されている全アドレスを表示してくれます。

% /usr/local/bin/fmlalias

「grep コマンドを使え！」と言いたいところですが、 grep では、うまくいきません。 というのは、メンバーリストがファイルだけとは限らないので、 すべて出力させてから grep してみないとわかりません。 たとえば (Unix らしく)、

% /usr/local/bin/fml ＭＬアドレス list | grep アドレス

また、ひんぱんに行うのであれば、 シェルスクリプトにするとよいですよ。

(1) fml8 のフィルタで弾かれている可能性があります。 fml8 のログを見て下さい。 通常 Mail コマンドは MIME ヘッダを生成しませんので、 fml8 では不正なメールとみなされます (注: デフォルトの fml4 では、 そこまで見てないのでエラーにならなかったはずです)。

(2) いまでは珍しいかもしれませんが、 そのＭＬサーバのホストの上からメールを送信するとエラーになることがあります。

[コマンドの例]

% echo test |Mail -s test elena@example.org

こういった場合には不完全な情報しか与えられていませんから、 メール全体を生成するのは Mail コマンド (もしくは Mail コマンドからメールを渡された MTA )の役目です。 ただし、こういった場合には、 From: の部分が「ユーザ」だけとか 「ユーザ＠ FQDN 」だったりします。 きちんと「ユーザ＠正しいドメイン」の形に生成されるようになっていないと fml8 としては正当なユーザに見えません(そしてフィルタで弾かれます)。

正しいドメインがつくように MTA の設定を直して下さい。

ログを見てみて下さい。

まず WWW サーバ側に出力されているログを確認して下さい。 fml からのエラーメッセージが記録されている可能性があります。

例:

/usr/local/apache/logs/error_log
/usr/local/apache/logs/suexec_log

/var/spool/ml 以下も確認してみましょう。 ＭＬのホームディレクトリすら出来ていないなら (そのＭＬのログファイルがありませんから) WWW サーバの処理の段階で何かがおかしいです。 まずは WWW サーバのログファイルを解析する必要があります。

中途半端にＭＬがセットアップされている (たとえばホームディレクトリはあるが、aliases に反映されていない) 場合には、fml のログファイル(例: /var/spool/ml/elena/log)を見てみて下さい。

MTA 間での再送エラーは MTA が再配送を試みます。 Sendmail の歴史的なパラメータが五日間でしたので、 「五日間は再配送を試みる」 MTA が多いと思います。

fml8 と MTA 間でエラーが生じた場合は fml8 のメールキューに入り、 fml8 が MTA への再送を試みます。 この部分の動作において fml8 は MTA です。

再送のタイミングは次に fml8 の何らかのプログラムが起動された時です。 そのため５分後などと確約は出来ません。 ５分ごとに再送を試みたい場合には、 cron で makefml ML flush を実行するようにしてみてください。

参考: the Chapter called fml8 のメール配送システム も参照してください。

the Section called 同じメールが何度も送られてくる場合 を参照してください。

the Section called 同じメールが何度も送られてくる場合 を参照してください。

(1) ＭＬの受信者の中にメールを転送している人がいると、 その転送先からエラーメールが管理者へ返ってくる可能性があります。

(2) SPAM メールです。

バグではなく MTA の仕様上、そうなる可能性があります。

たとえば aliases が次のようになっていたとします。

elena: rudo, kenken, hitomi

From: rudo
To: elena 
Cc: rudo 

test

elena ＭＬを fml に変更すると、 この MTA による重複削除の効果がなくなります。 そのため、 elena ＭＬ経由 rudo 宛にとどく分と rudo 宛に直接配送されてくる分の２つになるというわけです。

fml8 は flock(2) 必須ですので、fml8 は動きません (たぶん動くけど動作が変になります)。

ただ、flock(2) といっても、 実際には Perl の Fnctl モジュールを使っていて、 このモジュールが OS ごとの差異を吸収しています。 また、fcntl(2) は POSIX.1 ですので、 これが動かない OS は、よほど変な OS です。

fml4 と異なり fml8 では、そういうことは起こらないように作ってあります。 記事番号がアップデートできないなら、 そもそも fml8 の処理が途中で止まるようになっています。

このロジックに抜けがあって起きる可能性があるかもしれませんが、 実際にそういう現象がおきてみないとよくわかりません。

fml8 の耐久シミュレーションでは発生しませんでした。 きちんとロジックは動作しています。 いまのところ、大丈夫と信じています。

「間違えて makefml rmml を実行してしまった！」ということなら、 reviveml コマンドで復活できます。

「間違えて rm -fr してしまった！」ということなら、 fml8 では自動でバックアップなどしてないので打つ手はありません。

そういったミスオペレーションの可能性を考えて、つねに バックアップ をとっておくべきです。

それが「運用」ということであります。

安全に消せる領域は、ほとんどありません。

あえていえば、 ねんのため記録している受信メールおよび送信メールのキャッシュくらいです。 これは、各ＭＬのホームにある var/mail/incoming と var/mail/outgoing です。 また過去のログが不要であれば log を消すという案もありますが、 あまりおすすめできません。

いずれもデバッグに必要なので、あまりおすすめできません。 消す場合にも、他のマシンにバックアップをとったあと消してください。

別についている必要はありませんので、 それはエラーでも何でもありません。

また「ついていない」という意味を確認したほうがよいでしょう。 メールリーダが表示していないだけかもしれません。 その場合は、 メールヘッダをすべて表示するように設定し、 メールを確認してもらうようにして下さい。

なお、デフォルトでは fml8 が配送した記事には Reply-To: がついています。 具体的には、 もしメーリングリストに投稿された元メールに Reply-To: 指定があった場合は、 そのまま元の Reply-To: がついています。 もし元のメールに Reply-To: がないなら fml8 が適切なものをつけます。 たとえば、 記事であれば投稿用のアドレス、 コマンドメールの返事であればコマンドメールのアドレスです。

ただし fml8 が Reply-To: をつけないように設定してあるのならつきません。 元のメールに Reply-To: がない場合、 そのまま Reply-To: のないメールが配送されます。

まず「返信先」とは何のことをいっているのか？を確認しましょう。

おそらく、 「メールリーダで『返信』をクリックした際に、 表示された下書きメールの宛先が期待どおりでなかった」 ということをいっているのだとはおもいます。

ふつう、そのテンプレートで表示される宛先は元メールの Reply-To: もしくは From: が使われているはずです。 メールリーダで加工されていないヘッダを表示して、 どうなっているかを確認してもらって下さい。

なお、Reply-To: については前レシピを参照して下さい。

これは元のメールについていないためです。 そのため送信者のメールリーダがつけていないということになります。 どうにもなりません。

fml8 は References: や In-Reply-To: についてなにもしません。 素どおしです。

fml8 はこれらのヘッダフィールドに対して何もしません。 元のメールに In-Reply-To: や References: がないためと考えられます。

前レシピも参照して下さい。

全員なら fml8 に問題がある可能性もありますが、 一部の人だけ文字化けするのであれば、 その人たちのメール環境の問題です。

ただ元々のメールが特殊で、 一部の人だけ読めないという可能性 (たとえばマイクロソフト製品ユーザの人たちだけでうまくいく組み合わせ; メールとメールリーダの組合わせ) もありうるので、一概に読む側が悪いとも言い切れない気がしますが…

MIME ヘッダを見てメールリーダがよろしく頑張ってしまうので、 現代では問題とされないことが多くなってしまったかもしれません。

無理矢理 fml8 側で変換できないわけではありませんが、 整合性がとれなくなるので、やめたほうがいいでしょう。 メールリーダにおまかせです。

遠い外国ということでしょうか。 けっこうどうしょうもありませんが、ウエブメールなら読める可能性が高いです。 いずれにせよ読む側の問題なので fml8 で何かをすることは難しいでしょう。

gmail (gmail.com)のアカウントでも取ってもらえば即解決すると思います。

セキュリティポリシーの都合で gmail が使えないなどの場合は、 どこかのプロバイダから有料のメールアカウントを買ってもらってください。 数百円/月でしょうから。

未実装です [1]

fml8 では ISO-2022-JP に変換してから送信していますし、 ヘッダにも適切な Content-Type: をつけています。

化けるようなら、 これらの処理を行なうモジュールがうまく動作していない可能性があります。 ヘッダの確認と、そのメールの文字コードの確認をしてみてください。

また、 そのヘルプファイルと、 ヘルプを取り寄せるトリガーになったコマンドメールを送ってください。 分析したいと思います。

返されたエラーメッセージおよびログファイルを見てみて下さい。

ログに no such file とある場合は get しようとしたファイルがないということです。 そのメッセージの後にアクセスしようとしたファイルのフルパスが書いてあるので、 確認してみて下さい。

ログの invalid argument は、 指示されたパラメータの何かが不正であった場合にでます。 また、 指定した記事番号が存在しなかった場合にも、 このエラーメッセージが出ることがあります。

特殊な圧縮形式は未サポートです。 fml8 の get および mget は、 送り返す際に MIME/Multipart 形式しかサポートしていません。

メールアドレスの表現形式は制限されています。 表現の範囲は FML::Restriction::Base クラスに定義されており、 次のようになっています。

my $domain_regexp  = '[-A-Za-z0-9\.]+';    # domain of user@domain
my $user_regexp    = '[-A-Za-z0-9\._\+]+'; # user of user@domain

error: unsafe From: アドレス
error: ignore this request.

扱えるメールアドレスの表現形式が制限されているためです。 前レシピを参照してください。

そもそも、このアドレスには有効なユーザ部分がありません。 コメントだけですのでエラーになって当然です。

扱えるメールアドレスの表現形式は制限されています。 前々レシピも参照してください。