fmlconf コマンドが各MLの変数一覧を表示してくれます。どのML(実は適 当なMLでも良い)を指定しても良いので、fmlconf を実行して下さい。 たとえば
% /usr/local/bin/fmlconf test |grep fml_version fml_version = fml-devel current-20021029
答えは、たぶん 1.03 + よく分からないパッチ群です。 インストールした人なり、 使ったパッケージシステムの中をのぞきまくるかしてください。
一般論は存在しません。 DJB 教は「パッチをあてろ!」という運用を考えない文化なのでしょうがないです。
fmladdr コマンドが /etc/passwd で定義されているユーザと aliases ファイルに設定 されている全アドレスを表示してくれます。
% /usr/local/bin/fmladdr
Warning |
fmladdr コマンドと fmlalias コマンドの違いは、一覧に ユーザ( /etc/passwd で定義されているもの )を含むか否か?という点です。 fmladdr は含みます、fmlalias は含みません。 fmlalias は純粋に alias 群を表示します。 |
fmlalias コマンドが aliases ファイル(群)に設定されている全アドレスを表示してくれます。
% /usr/local/bin/fmlalias
Warning |
fmladdr コマンドと fmlalias コマンドの違いは、一覧に ユーザ( /etc/passwd で定義されているもの )を含むか否か?という点です。 fmladdr は含みます、fmlalias は含みません。 fmlalias は純粋に alias 群を表示します。 |
「grep コマンドを使え!」と言いたいところですが、 grep では駄目だめでしょう。 というのは、メンバーリストがファイルとは限らないので、 全て出力させてから grep してみないとわかりません。 たとえば
% /usr/local/bin/fml MLアドレス list|grep アドレスを各MLについて繰り返すという作業になります。
これでも面倒かなぁ、よっぽどひんぱんに行なう作業というのであれば、 それ用のコマンドを用意しても良いのですが、はてさて?
(1) fml8 のフィルタで弾かれている可能性があります。fml8 のログを見 て下さい。通常 Mail コマンドは MIME ヘッダを生成しませんので、fml8 では不正なメールとみなされます(注: デフォルトの fml4 では、そこまで 見てないのでエラーにならなかったはずです)。
(2) いまでは珍しいかもしれませんが、そのMLサーバのホストの上からメールを 送信するとエラーになることがあります。
[コマンドの例] % echo test |Mail -s test elena@fml.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 以下も確認してみましょう。 MLのホームディレクトリすら出来ていないなら (そのMLのログファイルがありませんから) WWW サーバの処理の段階で何かがおかしいです。 まずは WWW サーバのログファイルを解析する必要があります。
中途半端にMLがセットアップされている (たとえばホームディレクトリはあるが、aliases に反映されていない) 場合には、fml のログファイル(例: /var/spool/ml/elena/log)を見てみて下さい。
MTA 間での再送エラーは MTA が再配送を試みます。 Sendmail の歴史的なパラメータが五日間でしたので、 「五日間は再配送を試みる」 MTA が多いと思います。
fml8 と MTA 間でエラーが生じた場合は fml8 のメールキューに入り、 fml8 が MTA への再送を試みます。 この部分の動作において fml8 は MTA です。
再送のタイミングは次に fml8 の何らかのプログラムが起動された時です。 そのため5分後などと確約は出来ません。 5分ごとに再送を試みたい場合には、 cron で makefml ML flush を実行するようにしてみてください。
参考: Chapter 35 も参照してください。
the Section called 同じメールが何度も送られてくる場合 を参照してください。
the Section called 同じメールが何度も送られてくる場合 を参照してください。
(1) MLの受信者の中にメールを転送している人がいると、 その転送先からエラーメールが管理者へ返ってくる可能性があります。
(2) SPAM メールです。
バグではなく MTA の仕様上、そうなる可能性があります。
たとえば aliases が次のようになっていたとします。
elena: rudo, kenken, hitomiこの aliases のMLに
From: rudo To: elena Cc: rudo testというメールを投稿したとすると rudo には一通届くだけです。 MTA が elena MLの受信者を調べ rudo 宛の重複分を取りのぞいています。
elena MLを fml に変更すると、 この MTA による重複削除の効果がなくなります。そのため、 elena ML経由 rudo 宛にとどく分と rudo 宛に直接配送されてくる分の2つになるというわけです。
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 では自動でバックアップなどしてないので打つ手はありません。
そういったミスオペレーションの可能性を考えて、つねに バックアップ をとっておくべきです。
それが「運用」ということであります。
安全に消せる領域は、ほとんどありません。
あえていえば、ねんのため記録している受信したメールおよび送信したメール のログである各MLのホームにある 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 に問題がある可能性もありますが、 一部の人だけ文字化けするのであれば、 その人たちのメール環境の問題です。
ただ元々のメールが特殊で一部の人だけ読めないという可能性(たとえば M$ 星人の人たちだけで勝手に見えているようなメールとメールリーダの組合わせ) もありうるので、一概に読む側が悪いとも言い切れない気がしますが…
MIME ヘッダを見てメールリーダがよろしく頑張ってしまうので、 現代では問題とされないことが多くなってしまったかもしれません。
無理矢理 fml8 側で変換できないわけではありませんが、整合性がとれなくな るので、やめたほうがいいでしょう。メールリーダにおまかせです。
遠い外国ということでしょうか。 けっこうどうしょうもありませんが、ウエブメールなら読める可能性が高いです。 いずれにせよ読む側の問題なので fml8 で何かをすることは難しいでしょう。
gmail (gmail.com)のアカウントでも取ってもらえば即解決すると思います。
社用MLの場合だと問題ですが、その場合は会社でどっかのプロバイダから有 料のメールアカウントを買ってもらうとかしてもらってください。 数百円/月でしょう。
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.
author's homepage is www.fml.org/home/fukachan/.
Also, visit nuinui's world :) at www.nuinui.net.
For questions about FML, e-mail <fml-bugs@fml.org>.