Provided by: manpages-ja_0.5.0.0.20221215+dfsg-1_all 
名前
fetchmail - POP, IMAP, ETRN, ODMR 機能を持つサーバからメールを取得する
書式
fetchmail [option...] [mailserver...]
fetchmailconf
説明
fetchmail はメールを取得・転送するためのユーティリティです。 fetchmail はリモートのメール
サーバからメールを取得し、 これをローカル (クライアント) マシンの配送システムに転送しま
す。 受け取ったメールは、その後 mutt(1), elm(1), Mail(1) など、 普通のメールユーザエージェ
ントで扱うことができます。 fetchmail ユーティリティはデーモンモードで実行し、 指定した時間
間隔で 1 つあるいは複数のシステムを 繰り返しポーリングすることができます。
fetchmail プログラムは一般的なメール取得プロトコル (POP2, POP3, IMAP2bis, IMAP4, IMAPrev1)
の いずれかをサポートしているサーバからメールを集めてくることができます。 また、ESMTP の
ETRN 拡張と ODMR を使うこともできます。 (これらのプロトコルを説明している RFC 全ては、 こ
のオンラインマニュアルの最後に列挙します。)
fetchmail は基本的に (SLIP や PPP 等の) オンデマンド TCP/IP 接続上で使うためのものですが、
sendmail を使った (送信者開始の) SMTP トランザクションを セキュリティ上の理由から認めない
サイトでは、 メッセージ転送エージェントとしても役立つかもしれません。
それぞれのメッセージを取得すると、 通常 fetchmail は自身が動作しているマシン (localhost)
の 25 番ポートに SMTP 経由でこのメッセージを配送します。 この動作は、ちょうど通常の TCP/IP
接続上で メッセージが渡されたかのように行われます。 次に、メールはシステムの MDA (Mail
Delivery Agent (メール配送エージェント)、 普通は sendmail(8) ですが、システムによっては
smail, mmdf, exim, qmail 等が 使われているかもしれません) 経由でローカルに配送されます。
したがって、配送制御機構 (.forward ファイル等) は、 システムの MDA とローカル配送エージェ
ントを通じて 全て通常通り使うことができます。
25 番ポートのリスナはないが、fetchmail のコンパイル時に 信頼できるローカル MDA を検知また
は指定された場合、 代わりとしてローカル配信にその MDA を使います。 通常、ビルド時に
fetchmail は 実行可能プログラム procmail(1) と sendmail(1) のバイナリを探します。
プログラム fetchmailconf が使用可能であれば、このプログラムを使って fetchmailrc の設定ファ
イルを楽に設定・編集することができます。 このプログラムは X 上で動作し、 またシステム上に
Python 言語と Tk ツールキットがあることが必要です。 単独ユーザモード用に初めて fetchmail
を設定する場合には、 初心者モード (Novice mode) を使うことをお勧めします。 上級者モード
(Expert mode) を使うと、 マルチドロップ機能を含む fetchmail の設定を完全に制御することがで
きます。 どちらの場合でも、`Autoprobe (自動検出)' ボタンを押すと、 指定されたメールサーバ
が最もうまくサポートしているプロトコルを教えてくれ、 そのサーバで起こる可能性がある問題も
指摘してくれます。
一般的な操作
fetchmail の動作はコマンドラインオプションと実行制御ファイル ~/.fetchmailrc で制御すること
ができます。 実行制御ファイルの文法は後のセクションで説明します (このファイルは
fetchmailconf プログラムが編集します)。 コマンドラインオプションは、 ~/.fetchmailrc での宣
言を上書き指定します。
問い合わせは、コマンドラインのオプションの後に指定した 全てのサーバに対して行われます。 コ
マンド行でサーバを指定していない場合には、 ~/.fetchmailrc ファイルの `poll' エントリそれぞ
れに対して問い合わせが行われます。
fetchmail は、スクリプトやパイプラインで使いやすいように、 終了時に適切な終了コードを返す
ようになっています。 後述の「終了コード」セクションをご覧ください。
以下のオプションで fetchmail の動作が変わります。 一度うまく動作する .fetchmailrc ファイル
が設定できれば、その後は これらのオプションを指定する必要はほとんどないでしょう。
ほとんど全てのオプションには対応するキーワードがあり、これらは fetchmailrc ファイルで宣言
することができます。
ここでは一部の特殊なオプションは説明しておらず、 代わりに後述の「認証」と「デーモンモー
ド」に関するセクションで説明しています。
一般設定のオプション
-V, --version
お使いの fetchmail のバージョン情報を表示します。メールの取得は行いません。その代わ
り、 fetchmail が実際にサーバに接続した場合に使われるはずのオプション情報全てが、
指定されているそれぞれのサーバについて表示されます。 パスワードやその他の名称文字列
に含まれる表示不可能な文字は、 C 言語と同様にバックスラッシュを使った エスケープ
シーケンスとして表示されます。 このオプションは、 オプションが希望通りに設定されて
いることを確かめる際に便利です。
-c, --check
実際にはメールの取得や削除を行わず、 取得待ちのメールがあるかどうかを示すステータス
コードだけを返します (後述の「終了コード」を参照)。 このオプションはデーモンモード
を無効にします (無意味になるため)。 複数サイトへの問い合わせはうまく動作しません
し、 ETRN や ODMR でも動作しません。 既読であるが削除されていないメールがサーバの
メールボックスに残っており、 かつメール取得のプロトコルが保存されているメッセージと
新しいメッセージを区別できない場合には、偽を表す正の値が返されます。 つまり、このオ
プションは IMAP では動作し、POP3 では動作しません。 また、POP3 では時々失敗すること
があります。
-s, --silent
静粛モード。通常はメール取得の途中に標準エラー出力に出力される、 進行状況/ステータ
スメッセージを全て止めます (しかし、実際のエラーメッセージは止めません)。 --verbose
オプションはこのオプションを上書きします。
-v, --verbose
詳細表示モード。 fetchmail とメールサーバの間でやりとりされた制御メッセージを 全て
標準出力に出力します。 --silent オプションを上書きします。 このオプションを 2 つ付
けると (-v -v)、追加の診断情報が出力されます。
メールの扱いに関するオプション
-a, --all
(キーワード: fetchall) 古い (既読) メッセージと新しいメッセージを 両方ともメール
サーバから取得します。 デフォルトでは、サーバが既読の印を付けていないメッセージだけ
を取得します。 POP3 を使う場合、このオプションを指定すると TOP ではなく必ず RETR が
使われます。 POP2 のメール取得は、--all が常に有効であるかのように動作します (後述
の「取得失敗モード」を参照)。 このオプションは ETRN と ODMR では動作しません。
-k, --keep
(キーワード: keep) 取得したメッセージをリモートのメールサーバに残します。 通常
は、メールを取得した後に メールサーバのフォルダからメッセージが削除されます。 keep
オプションを指定すると、 取得したメッセージはメールサーバのユーザのフォルダに残りま
す。 このオプションは ETRN と ODMR では動作しません。
-K, --nokeep
(キーワード: nokeep) 取得したメッセージをリモートのメールサーバから削除します。 こ
のオプションを指定すると、取得したメールは削除されます。 .fetchmailrc 内 で keep を
デフォルト設定にしている場合には、 このオプションが役に立つかもしれません。 ETRN や
ODMR を使う場合には、このオプションは必ず有効にされます。
-F, --flush
POP3/IMAP 専用のオプションです。 新しいメッセージを取得する前に、古い (以前に取得し
た) メッセージをメールサーバから削除します。 このオプションは ETRN と ODMR では動作
しません。 注意: ローカルの MTA がハングし、fetchmail が異常終了した場合、 次回に
fetchmail を起動したときに配送されていないメールが消されてしまいます。 あなたが良い
と思うのはたぶんデフォルトの設定です: `-k' を指定しなければ、 fetchmail は配送が成
功した後に自動的にメッセージを削除します。
プロトコルと問い合わせのオプション
-p, --protocol <proto>
(キーワード: proto[col]) リモートのメールサーバと通信するときに使うプロトコルを指定
します。 プロトコルが指定されなければ、デフォルト値は AUTO です。 proto には以下の
どれかを指定することができます:
AUTO IMAP, POP3, POP2 に試します (サポートが組み込まれていないプロトコルは飛ばし
ます)。
POP2 Post Office Protocol 2
POP3 Post Office Protocol 3
APOP 古い形式の MD5 チャレンジ認証付きの POP3 を使います。
RPOP RPOP 認証付きの POP3 を使います。
KPOP ポート 1109 番で Kerberos V4 認証付きの POP3 を使います。
SDPS Demon Internet の SDPS 拡張付きの POP3 を使います。
IMAP IMAP2bis, IMAP4, IMAP4rev1 のいずれか (fetchmail はこれらの機能を自動的に検
出します)。
ETRN ESMTP の ETRN オプションを使います。
ODMR On-Demand Mail Relay の ESMTP プロファイルを使います。
ETRN と ODMR を除き、これらの選択オプションは基本的に全て同じ動作です (標準のサーバデーモ
ンと通信し、 サーバのメールボックスに配送されているメールを取得します)。 ETRN モードを使う
と、ESMTP 準拠のサーバ (BSD sendmail のリリース 8.8.0 以降など) に、 クラアイントマシンへ
の送信 SMTP 接続を即座に開かせ、 サーバの未配達メールのキューに入っている、 宛先がユーザの
クライアントマシンになっている 全てのメールの転送を開始させることができます。 ODMR モード
では ODMR が可能なサーバが必要で ETRN と同様に動作します。 ただし、ODMR モードではクライア
ントマシンに静的 DNS が必要ありません。
-U, --uidl
(キーワード: uidl) 必ず UIDL を使うようにします (POP3 の場合のみ有効です)。 メッ
セージの「新しさ」の確認が必ずクライアント側で行われるようになります (UIDL は
「unique ID listing (ユニークな ID の列挙)」を表します)。 `keep' と一緒に用い、メー
ルボックスを、 あるユーザグループ用の新しいニュースを入れておく場所として使ってくだ
さい。
-P, --port <ポート番号>
(キーワード: port) port オプションを使うと、接続する TCP/IP の ポート番号を指定する
ことができます。 このオプションが必要となることはほとんどないでしょう。 というの
も、サポートされている全てプロトコルにはよく知られているデフォルトの ポート番号があ
るからです。
--principal <principal>
(キーワード: principal) principal オプションを使うと、 相互認証のための principal
を指定することができます。 Kerberos 認証付きの POP3 と IMAP の場合に使用できます。
-t, --timeout <秒数>
(キーワード: timeout) timeout オプションを使うと、 サーバが応答しない際のタイムアウ
ト時間を秒単位で設定することができます。 指定された秒数の間メールサーバがグリーティ
ングメッセージを送ってこないか コマンドに応答しない場合、 fetchmail はサーバとの接
続を切ります。 このようなタイムアウトを使わなければ、 fetchmail は落ちているホスト
から いつまでもメールを取得しようとしてハングアップしてしまうかもしれません。 これ
は fetchmail がバックグラウンドで動作している時には 特にうっとうしいでしょう。 デ
フォルトのタイムアウト時間があり、fetchmail -V で表示することができます。 与えられ
た接続で何度も連続してタイムアウトを受けた場合、 fetchmail は接続が止められているも
のと考え、リトライを止めます。 これが起こった場合、接続を止められたユーザはメールで
通知を受けます。
--plugin <コマンド>
(キーワード: plugin) plugin オプションを使うと、TCP 接続を確立するための 外部プログ
ラムを使うことができます。 これは SOCKS, SSL, ssh を使う場合や ファイアウォール用の
特殊な設定が必要なときに便利です。 プログラムは $PATH 環境変数内で検索されます。 オ
プションとして、"%h" と "%p" を使って、 それぞれホスト名とポート名を引き数として渡
すこともできます (補間ロジックは少し原始的で、受け取られる引き数は空白で囲まれてい
るか、 文字列の先頭または末尾になければいけないことに注意して下さい)。 fetchmail は
プラグインの標準入力に書き込みを行い、 プラグインの標準出力から読み込みを行います。
--plugout <コマンド>
(キーワード: plugout) 前の項の plugin オプションと同じですが、 このオプションは
SMTP 接続に対してのみ使われます (SMTP 接続ではたぶんプラグインは不要なので、 plugin
オプションから分離されています)。
-r <フォルダ名>, --folder <フォルダ名>
(キーワード: folder[s]) メールサーバ上で、デフォルト以外の指定されたメールフォルダ
(またはコンマで区切ったフォルダのリスト) からメールを取得します。 フォルダ名の記法
はサーバに依存します。 このオプションは POP3, ETRN, ODMR では使えません。
--tracepolls
(キーワード: tracepolls) fetchmail が生成する Received 行に、 `polling %s account
%s' という形式でトレース情報を入れるようにさせます。 %s の部分はユーザのリモート名
とポーリングレベルに置き換えられます (通常、Received ヘッダにはサーバの本当の名前も
含まれます)。 これは、受信したアカウントに基づいたメールフィルタリングを 容易にする
ために使うことができます。
--ssl (キーワード: ssl) メールサーバへの接続を SSL を使って暗号化します。サーバへの接続
は、SSL によって守られた接続上で指定した基本プロトコルを使って行われます。 ポートが
指定されていない場合は、 接続は基本プロトコルの SSL 版の既知のポートで試みられま
す。 これは一般的には、基本プロトコルで使われるポートとは異なります。 IMAP の場
合、基本プロトコルはポート 143 であり、 SSL で守られたプロトコルの場合はポート 993
です。
--sslcert <名前>
(キーワード: sslcert) クライアント側の公開 SSL 証明書のファイル名を指定します。SSL
による 暗号化を行うサーバの一部には、認証のためにクライアント側の鍵と証明書を 必要
とするものもあります。ほとんどの場合はこれは省略してもかまいません。 このオプション
は SSL セッションを確立する時にサーバに示す公開鍵証明書 の位置を指定します。サーバ
が必要としなければ、これを指定する必要はあり ません (指定してもかまいません)。これ
を必要とするサーバもありますし、 要求するけれど必要とはしないサーバもありますし、全
く要求しないサーバも あります。これは秘密鍵 (鍵と証明書を一緒にしたファイル) と同じ
ファイルの こともありますが、これはお勧めできません。
--sslkey <ファイル名>
(キーワード: sslkey) クライアント側の秘密 SSL 鍵のファイル名を指定します。SSL によ
る 暗号化を行うサーバの一部には、認証のためにクライアント側の鍵と証明書を 必要とす
るものもあります。ほとんどの場合はこれは省略してもかまいません。 このオプションは
SSL セッションを確立する時にサーバとの署名トランザクション で用いる秘密鍵の位置を指
定します。サーバが必要としなければ、これを指定 する必要はありません (指定してもかま
いません)。これを必要とするサーバも ありますし、要求するけれど必要とはしないサーバ
もありますし、全く要求し ないサーバもあります。これは公開鍵 (鍵と証明書を一緒にした
ファイル) と同 じファイルのこともありますが、これはお勧めできません。鍵を外すために
パスワードが必要な場合には、サーバとのセッションを確立する直前に パスワードを聞かれ
ます。そのため、デーモンモードで使うのは困難です。
--sslproto <名前>
(キーワード: sslproto) ssl プロトコルを強制的に使用します。 指定可能な値は `ssl2',
`ssl3', `tls1' です。 サーバとのデフォルトの接続がうまく行かなかった場合に試して下
さい。
--sslcertck
(キーワード: sslcertck) fetchmail がローカルの信用できる証明書に対してサーバ証明書
を 厳密にチェックするようにします (sslcertpath オプションを見てください)。 サーバ証
明書が信頼できる署名で (直接的または間接的に) サインされていない場合、SSL 接続は失
敗します。 このチェックにより、SSL 接続に対して 経路の途中にいる人間が行う攻撃を阻
止できます。 OpenSSL による証明書確認では、 CRL は現在サポートされていないかもしれ
ない点に注意してください。 このオプションを使うと、システムクロックがいくらか進みま
す。
--sslcertpath <ディレクトリ名>
(キーワード: sslcertpath) fetchmail がローカルの証明書を探すディレクトリを設定しま
す。 デフォルトは OpenSSL のデフォルトのディレクトリです。 ディレクトリは OpenSSL
が期待するようにハッシュされなければなりません。 ディレクトリ内の証明書を追加・修正
した場合は、 (OpenSSL の tools/ サブディレクトリに入っている) c_rehash ツールを使う
必要があります。
--sslfingerprint
(キーワード: sslfingerprint) コロンで区切られた 16 進数表記の 2 組の数字で書かれた
サーバ・キーの署名 (キーの MD5 ハッシュ) を指定します。 16 進数の数字は大文字でなけ
ればなりません。 これは OpenSSL が使うデフォルトの形式で、 SSL 接続が確立されると
fetchmail はこの形式で署名を表示します。 このオプションが指定されると、 サーバ・
キーの署名を与えられた署名と比較します。 一致しなかった場合、接続は失敗します。 こ
れは経路の途中にいる人間が行う攻撃を阻止できます。
配送制御オプション
-S <hosts>, --smtphost <ホスト>
(キーワード: smtp[host]) メールを転送するホストのリスト (1 つ以上のホスト名で、コン
マで区切ります) を指定します。 ホストはリストの順に接続が試みられます。 最初の動作
しているホストが、 今回の動作における転送先対象となります。 通常は `localhost' がリ
ストの末尾に暗黙のデフォルト値として追加されています。 しかし、Kerberos 認証を使う
場合には、 fetchmail を実行しているマシンの FQDN がリストの末尾に 暗黙のデフォルト
値として追加されます。 それぞれのホスト名には、ホストの名前の次にポート番号が付いて
います。 ポート番号とホスト名はスラッシュで区切られます。 デフォルトのポート番号は
25 (IPv6 では ``smtp'') です。 (/ で始まる) 絶対パス名を指定した場合、 LMTP 接続を
受け付ける UNIX ソケットの名前として解釈されます (これは Cyrus IMAP デーモンでサ
ポートされます)。 例:
--smtphost server1,server2/2525,server3,/var/imap/socket/lmtp
このオプションは ODMR モードで使用することができ、 fetchmail に ODMR サーバと SMTP,
LMTP レシーバの間の リレーをさせます。
--fetchdomains <ホスト>
(キーワード: fetchdomains) ETRN と ODMR モードにおいて、このオプションは 接続が行わ
れた場合にサーバがメールを配送するドメインの一覧を指定します。 デフォルトは
fetchmail が稼働しているマシンの FQDN です。
-D <ドメイン>, --smtpaddress <ドメイン>
(キーワード: smtpaddress) アドレスに追加されるドメインを指定します。 このアドレスは
SMTP で送られる RCPT TO 行に入ります。 これが指定されなかったときは、SMTP サーバの
名前 (--smtphost で指定するか、デフォルトの "localhost") が使われます。
--smtpname <ユーザ@ドメイン>
(キーワード: smtpname) SMTP で送られる RCPT TO 行に入れられるドメインとユーザを指定
します。 デフォルトのユーザは現在のユーザです。
-Z <nnn>, --antispam <nnn[, nnn]...>
(キーワード: antispam) SMTP 受信プログラムからのスパム防止の応答と解釈される、 数値
形式の SMTPエラーのリストを指定します。 値が -1 であれば、このオプションは無効にさ
れます。 コマンドラインオプションの場合、 リストの値はコンマで区切らなければなりま
せん。
-m <コマンド>, --mda <コマンド>
(キーワード: mda) -mda あるいは -m オプションを使って、(25 番ポートに転送するのでは
なく) メールを直接 MDA に渡すようにできます。 メールを失うのを避けるために、 このオ
プションは、 ディスクが溢れている場合やリソース消費エラーなどの場合に 0 以外のス
テータスを返す procmail や sendmail といった MDA とともに使って下さい。 0 以外のス
テータスは fetchmail に配送が失敗したことを知らせ、 メッセージがサーバから削除され
るのを防止します。 fetchmail を root で実行すると、 ユーザ ID は MDA 経由でメールを
配送する間に対象ユーザのものに設定されます。 これが利用できる MDA には
"/usr/sbin/sendmail -oem -f %F %T", "/usr/bin/deliver", "/usr/bin/procmail -d %T"
があります (しかし、通常は後のものは冗長です。 なぜならこれは通常、SMTP リスナが転
送を行う先だからです)。 %T を置いた場所には、MDA コマンドに対してローカル配送アドレ
スが挿入されます。 メールのメッセージの From アドレスは、%F を置いた場所に挿入され
ます。 "sendmail -oem -t" のような、To/Cc/Bcc の内容宛に メールを発送する MDA の呼
び出しを用いてはいけません。 これをするとメールのループが発生し、 あなたが大勢の
postmaster から大目玉を食らうことになります。
--lmtp (キーワード: lmtp) LMTP (Local Mail Transfer Protocol) 経由の配送を行います。 この
オプションを選択した場合には、 smtphost で対象リストに指定した各ホストに対して、
サービスのポートを (スラッシュのサフィックスを用いて) 明示的に指定しなければなりま
せん。 デフォルトポートの 25 は (RFC 2033 によって) 認められていません。
--bsmtp <ファイル名>
(キーワード: bsmtp) 取得したメールを BSMTP ファイルに追加します。 これは単に、メー
ルを SMTP受信デーモンに渡すときに fetchmail が通常生成するであろう SMTP コマンドを
含んでいます。 引き数に `-' を指定すると、メールは標準出力に書き込まれます。
fetchmail が付け直した MAIL FROM と RCPT TO 行が正しいことの 保証はない点に注意して
ください。 後述の「マルチドロップメールボックスの利用と不正使用」の 議論における注
意事項が適用されます。
リソースの制限・制御のためのオプション
-l <最大バイト数>, --limit <最大バイト数>
(キーワード: limit) サイズの最大値を 10 進数で引き数に取ります。 このサイズより大き
いメッセージは取得されず、サーバ上に残されます (フォアグラウンドのセッションでは、
進行状況メッセージで "oversized (サイズ超過)" であると知らされます)。 メールの取得
に使われるプロトコル (特に fetchall オプションを指定しない IMAP または POP3) によっ
て 未読の印を付けることができる場合、 明示的に --limit に 0 を指定すると、 実行制御
ファイルで設定した上限値を全て上書きします。 このオプションは、電話料金が高くて変化
もするという理由から、 メール取得の時間を厳しく制御する必要がある人のためのもので
す。 デーモンモードでは、サイズ超過の通知は 呼び出しを行ったユーザに対してメールで
行われます (--warning オプションを参照)。 このオプションは ETRN と ODMR では使えま
せん。
-w <間隔>, --warnings <間隔>
(キーワード: warnings) 時間間隔を秒数で引き数に取ります。 デーモンモードで `limit'
オプションを付けて fetchmail を呼び出すと、このオプションはサイズを超過しているメッ
セージに関する警告が 呼び出したユーザ (または `postmaster' オプションで指定したユー
ザ) に メールで送られる時間間隔を制御します。 このような通知は常に、サイズを超過し
ているメッセージが見つかった 最初のポーリングの終了時にメールで送られます。 その後
は、警告時間間隔が経過するまで再通知は止められます (これは、後に続く最初のポーリン
グの終了時に行われます)。
-b <最大数>, --batchlimit <最大数>
(キーワード: batchlimit) 接続をわざと止めてから再接続するまでに SMTP 受信プログラム
に送信するメッセージの最大数を指定します (デフォルト値は 0 で、これは無制限を表しま
す)。 明示的に --batchlimit に 0 を指定すると、 実行制御ファイルで設定されている上
限値は全て上書きされます。 sendmail(8) は通常、 メッセージ終端子を受信した直後に
メッセージの配送を始めますが、 そんなに素早く応答しない SMTP 受信プログラムもありま
す。 qmail(8) や smail(8) 等の MTA は、 配送ソケットが閉じられるまで配送を待つこと
があります。 fetchmail が巨大なバッチ処理を行っている時には、 これはうっとうしい遅
れを引き起こすかもしれません。 バッチの上限値にゼロでない値を何か設定しておくと、
このような遅れを防ぐことができます。 このオプションは ETRN と ODMR では動作しませ
ん。
-B <上限値>, --fetchlimit <上限値>
(キーワード: fetchlimit) 指定されたサーバ 1 つからの 1 度のポーリングで取得できる
メッセージ数を制限します。 デフォルトでは制限はありません。 明示的に --fetchlimit
に 0 を設定すると、 実行制御ファイルで設定した上限値を全て上書きします。 このオプ
ションは ETRN と ODMR では動作しません。
-e <メッセージ数>, --expunge <メッセージ数>
(キーワード: expunge) 指定された数のメッセージの後に削除が行われるようにします。
POP2 や POP3 の場合には、fetchmail は QUIT を送って セッションを終わらなければ削除
を行うことができません。 したがってこのオプションを on にすると、 fetchmail は長い
メール取得セッションを複数のサブセッションに分割し、 各サブセッションの後に QUIT を
送ります。 これは、回線が切れた時に QUIT と同等の処理を行わない POP3 サーバで起こる
行落ちに対する良い対策になります。 IMAP の場合には、 fetchmail は削除を即座に行わせ
るために、 削除を行うたびに EXPUNGE コマンドを発行するのが普通です。 これはサーバと
の通信が不安定な時や高価な時には非常に安全な方法です。 というのも、接続が切れてし
まった後に 同じメールを再び受け取らなくて済むからです。 しかしメールボックスが大き
い場合には、 メッセージを消すたびごとにインデックスを付け直す時のオーバーヘッドで、
サーバがかなり大変な目に遭うかもしれません。 ですから、接続の信頼性が高い場合には、
削除を行う間隔は長くしたほうが良いでしょう。 このオプションに整数 N を指定すると、
fetchmail は N 回目の削除の時だけ実際の削除を行います。 引き数に 0 を指定すると、削
除は全く行われなくなります (したがって、実行終了時まで削除は全く行われません)。 こ
のオプションは ETRN と ODMR では動作しません。
認証に関するオプション
-u <ユーザ名>, --username <ユーザ名>
(キーワード: user[name]) メールサーバにログインするときに使うユーザ識別情報を指定し
ます。 適切なユーザ識別情報はメールサーバとユーザの両方に依存します。 デフォルト値
は fetchmail を実行したクライアントマシン上でのログイン名です。
-I <インタフェース指定>, --interface <インタフェース指定>
(キーワード: interface) ポーリングを行う前に、特定のインタフェースデバイスが動作し
ていることと、 特定のローカルまたはリモートの IP アドレス (またはアドレス範囲) を持
つことを要求します。 fetchmail は SLIP や PPP 経由でメールサーバに対して直接確立さ
れた point-to-point の TCP/IP リンク上で使われることがよくあります。 これは比較的安
全なチャネルです。 しかし、メールサーバへの他の TCP/IP 経路が存在するとき (例: リン
クが別の ISP に接続されているとき)、 あなたのユーザ名とパスワードは盗聴に対して脆弱
です (特にデーモンモードが自動的にメールをポーリングし、 平文のパスワードを予測可能
な間隔でネットワーク上に流している場合)。 --interface オプションを使うと、これを防
ぐことができます。 指定されたリンクが上がっていないときや、 マッチする IP アドレス
に接続されていないときには、 ポーリングは飛ばされます。 フォーマットは以下です:
interface/iii.iii.iii.iii/mmm.mmm.mmm.mmm
最初のスラッシュの前のフィールドはインタフェース名です (つまり、sl0, ppp0 等)。 2
番目のスラッシュの前のフィールドは許可される IP アドレスです。 2 番目のスラッシュの
後のフィールドは、許可する IP アドレスの範囲を 指定するマスク値です。 マスクがない
場合には、255.255.255.255 (つまり、完全なマッチ) が指定されたものとして扱われます。
このオプションを現在サポートしているのは Linux と FreeBSD だけです。 FreeBSD 固有の
情報については、後述の monitor セクションをご覧ください。
-M <インタフェース>, --monitor <インタフェース>
(キーワード: monitor) デーモンモードでは、アクティブでない状態が一定時間続くと、 自
動的に切断される一時的なリンク (例: PPP 接続) が いつまでも接続したままになる可能性
があります。 このオプションはアクティブ状態を監視する システムの TCP/IP インタ
フェースを指定します。 毎回のポーリング間隔の後、リンクが確立しているけれど そのリ
ンク上で他の通信がされていなければ、ポーリングは飛ばされます。 しかし、fetchmail が
シグナルで起動された場合は、 監視のチェックは飛ばされ、無条件にポーリングが行われま
す。 このオプションは現在 Linux と FreeBSD でのみサポートされています。 FreeBSD の
場合、 monitor オプションと interface オプションを root 以外のユーザで動作させるに
は、SGID kmem して fetchmail のバイナリをインストールしなければなりません。 これは
セキュリティホールになるかもしれませんが、 fetchmail はインタフェースのデータを集め
るとき だけ 実効 GID を kmem グループに設定して動作します。
--auth <タイプ>
(キーワード: auth[enticate]) このオプションを使うと認証のタイプを指定することができ
ます (詳しくは「ユーザ認証」の項をご覧ください)。 指定可能な値は、any, `password',
`kerberos_v5', `kerberos' (非常に正確に言うと `kerberos_v4'), gssapi, cram-md5,
otp, ntlm, ssh です。 (デフォルトの) any を指定すると、 fetchmail は、まず最初にパ
スワードを必要としない方法 (GSSAPI, KERBEROS_IV) を試します。 次にパスワードを隠す
方法 (CRAM-MD5, X-OTP, NTLM) を探します。 そして、サーバがこれらの方法のどれもサ
ポートしていない場合にのみ、 パスワードを平文で渡します。 それ以外の値は、いろいろ
な認証方法を強制するために使われます (ssh は認証をさせないようにします)。 password,
cram-md5, ntlm, otp 以外の値では、 fetchmail による通常のパスワード問い合わせをさせ
ないようにします。 ssh トンネルのような end-to-end の安全な接続を使っている場合に、
ssh を指定して下さい。 GSSAPI または K4 を使ったプロトコルを使っている場合は、
gssapi または kerberos_v4 を指定して下さい。 KPOP プロトコルを選択すると自動的に
Kerberos 認証が選択されます。 このオプションは ETRN では動作しません。
その他のオプション
-f <パス名>, --fetchmailrc <パス名>
~/.fetchmailrc 実行制御ファイルとしてデフォルトでない名前を指定します。 <パス名> 引
き数は "-" (ダッシュ 1 つ、標準入力から設定を読み込むことを意味します) またはファイ
ル名でなければなりません。 同時に --version オプションも有効にしていない場合、 指定
されたファイル引き数は 0600 (u=rw,g=,o=) 以外のパーミッションを持っているか、 そう
でなければ /dev/null でなければなりません。
-i <パス名>, --idfile <パス名>
(キーワード: idfile) POP3 の UID を保存するために使う .fetchids ファイルに別の名前
を指定します。
-n, --norewrite
(キーワード: no rewrite) 通常、 fetchmail は取得したメール中の RFC-822 のアドレス
ヘッダ (To, From, Cc, Bcc, Reply-To) を編集し、 サーバに対してローカルなメールの ID
が完全なアドレスに展開されます (@ とメールサーバのホスト名が追加されます)。 これに
より、クライアントにおけるリプライで 宛先を正しくすることが可能になります (このよう
にしない場合、メーラはクライアントマシンの ローカルユーザに送るべきだと考えるかもし
れません!)。 このオプションはこの書き換えを無効にします。 (このオプションは、MTA が
メールのヘッダを編集することに対して神経質で、 これを止められることを知りたい人々を
なだめるために用意しています。 しかし一般的には、実際に書き換えを止めるのは良い考え
ではありません。) ETRN や ODMR を使うときには、書き換えオプションは無効です。
-E <envelope 行>, --envelope <envelope 行>
(キーワード: envelope) このオプションは、 fetchmail がメールの envelope アドレスの
コピーを運ぶと想定するヘッダを変更します。 通常これは `X-Envelope-To' ですが、これ
は標準ヘッダではないので、 実際には別のものになることがあります。 後述のマルチド
ロップアドレス処理に関する議論を参照してください。 特殊な場合として、`envelope
"Received"' を設定すると sendmail 形式の Received 行を処理することが可能になりま
す。 このオプションはデフォルトですが、.fetchmailrc ファイルで `no envelope' を使っ
て Received の処理を動作全体で無効にしていなければ、 必ずしも必要はないはずです。
-Q <プレフィックス>, --qvirtual <プレフィックス>
(キーワード: qvirtual) このオプションに割り当てられた文字列プレフィックスは、
envelope オプションで指定されたヘッダ内で見つかった ユーザ名から削除されます (マル
チドロップの名前マッチングか ローカルドメインのチェックのどちらかが利用できる場合、
これらを行う前に削除が行われます)。 このオプションは fetchmail を使ってドメイン全体
のメールを集めている場合と、 お使いの ISP (またはメール転送プロバイダ) が qmail を
使っている場合に便利です。 qmail の基本機能の 1 つに
`Delivered-To:'
があります。 qmail はローカルのメールボックスにメッセージを配達するときには必ず、
ユーザ名と envelope recipient のホスト名をこの行に書きます。 これは主にメールのルー
プを防ぐために行います。 接続されていないサイトに一括でメールを送る qmail の設定を
行うため、 ISP のメールホストはそのサイトを `Virtualhosts' 制御ファイルに書いておく
のが普通であり、 これによりそのサイト宛のメールアドレス全てにプレフィックスが追加さ
れます。 その結果、'username@userhost.userdom.dom.com' 宛に送られたメールの
`Delivered-To:' 行は以下のような形になります:
Delivered-To: mbox-userstr-username@userhost.userdom.dom.com
ISP は 'mbox-userstr-' プレフィックスを自由に決められますが、 よく選ばれるのはユー
ザのホスト名にマッチする文字列です。 オプション `envelope Delivered-To:' を使うこと
により、 fetchmail に元の envelope recipient を識別させることが安全に行えますが、
正しいユーザにメールを配達するには `mbox-userstr-' プレフィックスを 取り除かなけれ
ばなりません。 これがこのオプションの目的です。
--configdump
~/.fetchmailrc を処理し、指定されたコマンドラインオプションを全て解釈し、 標準出力
に設定情報を出力します。 設定情報は Python 言語のデータ構造配置になっています。 こ
のオプションは fetchmailconf のような Python で書かれた対話的な ~/.fetchmailrc エ
ディタと一緒に使うためのものです。
ユーザ認証と暗号化
ETRN を除く全てのモードではクライアントの認証が必要です。 fetchmail における通常のユーザ認
証は、 ftp(1) の認証機構によく似ています。 正しいユーザ ID とパスワードは、 メールサーバの
内部的なセキュリティシステムに依存します。
メールサーバが、あなたが通常のユーザアカウントを持っている Unix マシンならば、 あなたがい
つも使っているログイン名とパスワードを fetchmail でも使ってください。 サーバとクライアント
の両方で同じログイン名を使っている場合、 -u オプションでわざわざユーザ ID を指定する必要は
ありません。 というのも、デフォルトの動作ではクライアントマシン上での ログイン名をサーバマ
シンのユーザ ID として使うからです。 サーバマシンでは別のログイン名を使っている場合には、
-u オプションでログイン名を指定してください。 例えば、'mailgrunt' という名前のマシンでのロ
グイン名が 'jsmith' である場合、 以下のようにして fetchmail を起動することになるでしょう:
fetchmail -u jsmith mailgrunt
fetchmail のデフォルトの動作では、接続が確立される前に ユーザにメールサーバのパスワードを
問い合わせます。 これは最も安全に fetchmail を使う方法であり、パスワードも盗まれにくなりま
す。 パスワードは ~/.fetchmailrc ファイルで指定することもできます。 これはデーモンモードや
スクリプトで fetchmail を使う場合に便利です。
パスワードを指定されておらず、 fetchmail が ~/.fetchmailrc ファイルからパスワードを展開で
きなかった場合、 fetchmail は対話的にパスワードを聞く前にユーザのホームディレクトリの
~/.netrc ファイルを探します。 このファイル中に、ユーザのメールサーバにマッチするエントリが
あった場合、 そのパスワードが使われます。 fetchmail は poll 名にマッチするものを最初に探し
ます。 これが見つからなければ、via 名にマッチするものをチェックします。 ~/.netrc ファイル
の詳しい文法については、オンラインマニュアルの ftp(1) を参照してください。 (この機能を使う
と、複数のファイルにパスワード情報が 分かれることを避けることができます。)
通常のユーザアカウントを与えないメールサーバでは普通、 ユーザ ID とパスワードはサーバに
メールボックスを与えるときに サーバの管理者が割り当てます。 メールボックスのアカウント用の
正しいユーザ ID とパスワードが分からなければ、 サーバの管理者に連絡しましょう。
古いバージョンの POP3 (RFC1081, RFC1225) は メールサーバ側で rhosts を用いる大雑把な形式の
独自の認証をサポートしていました。 この RPOP の変種では、パスワードと同等であるユーザごと
の固定 ID は、 予約ポートとの接続上で平文のまま送信されていました。 このとき、PASS コマン
ドでなく RPOPコマンドを使って、 特殊なチェックが必要なことをサーバに知らせていました。
fetchmail は RPOP をサポートしています (`protocol RPOP' を指定すると、 fetchmail に `PASS'
ではなく `RPOP' を送らせることができます) が、 これは使わないことを強くお勧めします。 この
機能は盗聴に弱いため、RFC1460 において削除されました。
RFC1460 で APOP 認証が導入されました。 この POP3 の変種では、APOP パスワードをサーバホスト
に登録します (サーバ上でこれを行うプログラムは、 たぶん popauth(8) と呼ばれるものです)。
~/.fetchmailrc ファイルには、これと同じパスワードを書いてください。 fetchmail がログインす
るたびに、パスワードとサーバにおけるグリーティング時刻の 暗号学的に安全なハッシュ値がサー
バに送られます。 これは、認証データベースのチェックによって検査できます。
お使いの fetchmail が Kerberos のサポート付きで構築されており、 かつ Kerberos 認証を指定
(--auth か .fetchmailrc での authenticate kerberos_v4 オプションを用います) した場合、
fetchmail は問い合わせ開始時に 毎回 Kerberos チケットを取得しようとします。 注意: poll 名
か via 名のどちらかが `hesiod' ならば、 fetchmail はメールサーバの検索に Hesiod を使おうと
します。
GSSAPI 認証による POP3 や IMAP を使う場合、 fetchmail はサーバが RFC1731 または RFC1734 に
準拠する GSSAPI 機能を備えていると仮定して使用します。 現在、この機能は Kerberos V 上でし
かテストされていないので、 既に tiket-granting チケットを持っていることを仮定します。 標準
の --user コマンドや .fetchmailrc の user オプションを 使って、主に使っている名前とは別の
ユーザ名を渡すことができます。
お使いの IMAP デーモンがグリーティング行で PREAUTH レスポンスを返した場合には、 fetchmail
はこれを通知して、通常の認証手順を飛ばします。 これは例えば ssh を明示的に用いて imapd を
起動している場合などに便利です。 この場合、fetchmail が起動したときに パスワードを問い合わ
せるのを止めさせるために、 そのサイトでの認証の値 `ssh' を宣言できます。
POP3 を使う場合には、サーバは RFC1938 準拠の 使い捨てパスワードのチャレンジ文字列を発行
し、 fetchmail はユーザのパスワードをパスフレーズとして使って、 必要とされるレスポンス文字
列を生成します。 これにより、ネットワーク上に 暗号化されていない機密情報を流すことを避ける
ことができます。
Compuserve の RPA 認証 (APOP に似ています) がサポートされています。 このサポートを組み込ん
でいる場合、 ホスト名の中に "@compuserve.com" が見つかると、 fetchmail はパスワードを平文
で送らず、 RPA パスフレーズを用いた認証を実行しようとします。
IMAP を使っている場合、 (Microsoft Exchange が使う) Microsoft の NTLM 認証 がサポートされ
ます。 このサポートを組み込んでいる場合、サーバが機能を示す応答で 「AUTH=NTLM」を返す
と、fetchmail は (パスワードを平文で送らないで) NTLM 認証を実行しようとします。 「ユーザ
名@ドメイン名」の形で user オプションを指定してください: 「@」の左の部分はユーザ名として渡
され、 「@」の右の部分は NTLM ドメインとして渡されます。
IPsec を使っている場合には、-T (--netsec) オプションを使うと、 外向きの IP 接続が初期化さ
れるときに使われる IP セキュリティリクエストを渡すことができます。 これは .fetchmailrc
ファイルで `netsec' サーバオプションを 使って行うこともできます。 どちらの場合でも、オプ
ションの値は inet6_apps ライブラリの net_security_strtorequest() 関数が受け付ける フォー
マットの文字列です。
--ssl オプションを使うと SSL で暗号化されたサービスにアクセスできます。 これは
.fetchmailrc ファイルで "ssl" サーバオプションを使っても行えます。 SSL による暗号化を有効
にすると、 SSL セッションの調停の後に SSL 接続上で問い合わせが行われます。 POP3 や IMAP と
いった一部のサービスでは、 SSL による暗号化サービスのために標準プロトコルとは別に 既知の
ポートが定義されています。 SSL が有効にされており、かつ明示的にポートが指定されていなけれ
ば、 暗号化通信のポートは自動的に選択されます。
SSL による暗号化を行うサーバに接続するとき、 サーバは身元確認のためにクライアントに証明書
を示します。 証明書はチェックされ、接続しようとしているサーバの名前が 証明書の中の標準名と
一致することと、 証明書に書かれている有効期限によると 現在証明書が有効であることが確かめら
れます。 どちらかのチェックが失敗すると警告メッセージが表示されますが、 接続は継続されま
す。 サーバの証明書は特定の認証機関 (CA, Certification Authority) によって 署名されている
必要はありませんし、 「自分で署名した」証明書であってもかまいません。
SSL による暗号化を行うサーバによっては、 クライアント側の証明書を要求することがあります。
クライアント側の公開 SSL 証明書と秘密 SSL 鍵を指定できます。 サーバが証明書を要求した
ら、クライアントの証明書は 身元確認のためにサーバに送られます。 サーバによっては正当なクラ
イアントの証明書を要求し、 証明書が送られないか正当でなければ接続を拒否するものがありま
す。 サーバによっては、認められている認証機関よる署名が クライアント側の証明書になされてい
ることが必要なものもあります。 鍵ファイルと証明書ファイルのフォーマットは、 内部的に動作し
ている SSL ライブラリが必要とする形式 (一般的には OpenSSL) です。
最後に、SSL の使用について注意書きをします : ネットワーク越しに自分で署名したサーバの証明
書を取得するという 上で述べたような設定では、 消極的な盗み聞きをする相手からは守れますが、
積極的に攻撃してくる相手から守るための助けにはなりません。 パスワードを平文で送るのに比べ
れば、かなり改善されますが、 中継点にいる相手からの攻撃は
(http://www.monkey.org/~dugsong/dsniff/ にある dsniff のようなツールを使うと特に) 簡単に可
能であることを知っておかなければなりません。 自分のメールボックスのセキュリティを真剣に考
えるなら、 ssh トンネル (下記の例を参照) をお勧めします。
デーモンモード
--daemon <間隔> または -d <間隔> を使うと fetchmail をデーモンモードで実行できます。 引き
数として、ポーリングの時間間隔を秒数で指定しなければなりません。
デーモンモードでは、 fetchmail は自分自身をバックグラウンドでずっと動作させます。 つま
り、指定された各ホストへの問い合わせと、 指定された時間のスリープを繰り返します。
したがって、単に
fetchmail -d 900
を実行すると、 ~/.fetchmailrc に記述された全てのホスト (キーワード `skip' で明示的に除外さ
れたホストは除きます) に対して 15 分ごとに 1 回ポーリングを行います。
`set daemon <interval>' を ~/.fetchmailrc ファイルに書くことでポーリング間隔を設定すること
が可能です。 ここで、<interval> は秒数を表す整数値です。 これを行うと、コマンドラインオプ
ションの --daemon 0 または -d0 で上書きしない限り、 fetchmail は必ずデーモンモードで起動し
ます。
ユーザあたり 1 つのデーモンプロセスしか許されません。 デーモンモードでは、 fetchmail は
ユーザ単位のロックファイルを作成してこれを保証します。
通常は、バックグラウンドでデーモンを動作している時に fetchmail を呼び出すと、 デーモンに対
して起動のシグナルを送信し、 即座にメールサーバにポーリングさせることができます。
(fatchmali を root で実行していれば起動シグナルは SIGHUP で、 それ以外のユーザであれば
SIGUSR1 です。) 起動の動作では、認証の失敗や複数回のタイムアウトによって 接続が「刺さって
いる」ことを示すフラグが全てクリアされます。
オプション --quit は、デーモンを起動させるのではなく、動作しているデーモンを殺します (その
ようなプロセスが無ければ fetchmail が知らせてくれます)。 --quit オプションが唯一のコマンド
ラインオプションならば、 この動作だけを行います。
quit オプションは他のコマンドラインオプションと一緒に使うこともできます。 この場合の動作と
しては、他のオプションと実行制御ファイルを組み合わせて 指定されていることを行う前に、動作
しているデーモンを全て殺します。
-L <ファイル名> または --logfile <ファイル名> オプション (キーワード: set logfile) を使う
と、 端末と切り離されている間に発生した状態メッセージを、 指定されたログファイル (オプショ
ンの後にログファイル名を続けてください) に リダイレクトすることができます。 ログファイルは
追加モードでオープンされるので、 以前のメッセージは削除されません。 このオプションは主にデ
バッグ用の設定の場合に役に立ちます。
--syslog オプション (キーワード: set syslog) を使うと、 可能であれば、発生した状態メッセー
ジとエラーメッセージを syslog(3) システムデーモンに送ります。 メッセージは fetchmail の
ID, LOG_MAIL の機能、 LOG_ERR, LOG_ALERT, LOG_INFO いずれかの優先度と一緒に記録されます。
このオプションは、サーバからメールを取得している間のデーモンの状態と 結果を示す状態メッ
セージとエラーメッセージを記録するためのものです。 この場合でも、コマンドラインオプション
と .fetchmailrc の処理に対する エラーメッセージは標準エラー出力か指定されたログファイルに
書かれます。 --nosyslog オプションは、これが ~/.fetchmailrc 内で有効にされているか、 -L
<ファイル名> または --logfile <ファイル名> オプションが使われているものとして syslog(3) の
使用を無効にします。
-N または --nodetach オプションは、デーモンプロセスの制御端末からの バックグラウンド化や切
り離しを止めます。 これは主にデバッグ時に有効です。 このオプションは logfile オプションも
無効にしてしまう点に注意してください (たぶんこれではいけないのですが)。
デーモンモードで動作して POP2 や IMAP2bis サーバに対して ポーリングしている時には、 一時的
エラー (DNS 参照失敗や sendmail の配送拒否など) が起こると 次のポーリング周期の間には
fetchall オプションが有効となります。 これは頑健さを実現する機能です。 つまり、メッセージ
を取得できた (そしてメールサーバでは既読の印が付けられた) けれど、 一時的エラーのために
ローカルでは配送されなかった場合、 そのメールは次のポーリング周期のときに再び取得されま
す。 (IMAP の仕組みではメッセージは配達されるまで消去されません。 したがって、このような問
題は起こりません。)
fetchmail がデーモンモードで動作している時に ~/.fetchmailrc ファイルを touch したり変更す
ると、これは次回のポーリングが始まる時に 検出されます。 ~/.fetchmailrc の変更が検出される
と、fetchmail はこのファイルを読み込み直し、 自分自身を最初から起動し直します (exec(2) を
使います。 新しく動作する fetchmail には、状態に関するそれまでの情報は一切残りません)。
~/.fetchmailrc ファイルの文法に違反していると、 新しい fetchmail は起動時に黙って静かに消
えてしまうでしょう。
管理用オプション
--postmaster <ユーザ名> オプション (キーワード: set postmaster) は、 ローカルでメールを受
け取る適切なユーザが見つからなかった場合に、 マルチドロップメールが転送される最終地点にな
るユーザ名を指定します。 通常、これは単に fetchmail を起動したユーザです。 起動したユーザ
が root であれば、 このオプションのデフォルト値はユーザ `postmaster' になります。
postmaster のユーザ名を空の文字列に設定すると、このようなメールは破棄されます。
--nobounce オプションは、RFC1894 準拠のエラーメッセージのうち、 送信者に戻される差戻しエ
ラー (bouncing error) の通常の動作を止めます。 nobounce が有効な場合、メッセージは送信者で
はなく postmaster に送られます。
--invisible オプション (キーワード: set invisible) は fetchmail を見えなくしようとします。
通常、fetchmail は他の MTA と同じように振舞います。 つまり、送信の経路が記述されている
Received ヘッダをメッセージ全てに書き込み、 転送先の MTA に、fetchmail そのものが実行され
ているマシンから メールが来たことを知らせます。 invisible オプションが有効である場合は、
Received ヘッダは付けられず、fetchmail は転送先の MTA をだまして、 メールがメールサーバの
ホストから直接届いたと思わせようとします。
--showdots オプション (キーワード: set showdots) は、 たとえ現在の端末 (tty) が標準出力で
ない場合 (例えばログファイルの場合) でも、進捗状況を表すドットを表示する。 fetchmail バー
ジョン 5.3.0 を起動した場合、 デフォルトでは進捗状況を表すドットは標準出力にしか表示されま
せん。
--tracepolls オプションを指定することにより、fetchmail に対して "polling {label} account
{user}" という形式の情報を Received ヘッダに加えるように指示することができます。 ここ
で、{label} は (指定された設定ファイル、 通常は ~/.fetchmailrc での) アカウントラベルで
す。 また、{user} はメールサーバにログオンするためのユーザ名です。 このヘッダは、役立つ
ヘッダ情報のない E メールをフィルタリングしたり、 アカウント毎のメールを別々のメールボック
スに ソートして入れるのに使うことができます (例えば、メーリングリストが運営されているサー
バにアカウントがあり、 そのアカウントを使ってメーリングリストを購読している場合に 使うこと
ができます)。 デフォルトでは、このようなヘッダは追加されません。 これは .fetchmailrc では
`tracepolls' というキーワードになります。
取得失敗モード
fetchmail がメールサーバと対話する際に使うプロトコルは、かなり安全です。 25 番ポートへの転
送を行う通常の操作では、 クライアント上の SMTP 受信プログラムが fetchmail に対して 配送す
るメッセージを受け取ったことを知らせたり、 スパム防御のために拒否したりするまでは、 (削除
の印が付いていたとしても) ホスト上のいかなるメッセージも消されません。
しかし、MDA に転送する時には、エラーの可能性はずっと高くなります MDA のなかには「安全」な
ものもあり、 配送エラーの場合や一時的なリソース資源を使い果たした場合にも、 0 以外のステー
タスを必ず返してくれます。 有名な procmail(1) プログラムは、このような動作をします。
sendmail(1) や exim(1) のようなメール転送エージェントとしてデザインされた大部分のプログラ
ムも、 このような動作をします。 これらのプログラムは信頼できる積極的な返答を返してくれるの
で、 メールを失うリスクを負うことなく、 mda オプションをつけて使うことができます。 しかし
安全でない MDA では、配送が失敗した場合でも 0 を返します。 このような事が起これば、メール
がなくなるでしょう。
fetchmail の通常モードは、 「新しい」メッセージだけをダウンロードしようとし、 サーバから既
に直接読み出した (あるいは、以前に fetchmail --keep を使って受け取った) メールには関与しま
せん (削除もしません)。 しかし、--all を指定していない場合でさえ、サーバ上にある 既読の
メールが取得される (そして削除される) ことがあることに お気づきになるでしょう。 このような
ことが起こる理由はいくつかあります。
まず POP2 を使っている場合が考えられます。 POP2 プロトコルには、メッセージの「新規」や「既
読」の状態を 表現する方法がありません。 したがって、fetchmail は必ず全てのメッセージを 新
しいものとして扱わなければなりません。 しかし、POP2 は古くて使われなくなっているので、 こ
れが原因のことはあまりないでしょう。
POP3 の場合には、RFC1725 を恨んでください。 このバージョンの POP3 プロトコルの仕様では
LAST コマンドが無くなっているのですが、 一部の POP サーバがこれに準拠しているのです (これ
を調べるには、メールサーバに対して fetchmail -v を実行して、 問い合わせの最初の方で行われ
る LAST コマンドへの応答を見てください)。 fetchmail のコードでは POP3 の UID 機能を使って
埋め合わせをしようとしています。 これは、それぞれのセッションで見たメッセージの識別子を、
次のセッションまで .fetchids に保存しておくという方法です。 しかしこの方法では、他のクライ
アントで見たメッセージや、 ホスト上のメーラで直接読まれたけれど その後で消されていないメッ
セージまでは追いかけられません。 IMAP に乗り換える方がいいでしょう。
他に起こる可能性がある POP3 の問題として、 メールボックスの途中にメッセージを挿入するサー
バが考えられます (VMS のメールの実装の一部に、このようなものがあると言われています)。
fetchmail のコードでは、 新しいメールはメールボックスの最後に追加されることを想定していま
す。 これが成り立っていなければ、 古いメッセージの一部が新しいものとして扱われることがあり
ますし、 その逆も起こります。 この問題を真っ当に解決する唯一の方法は、IMAP に乗り換えるこ
とです。
POP3 の別の問題として、 ユーザのホームディレクトリに一時ファイルが作成できない場合に、 一
部の POP3 サーバは文書化されていない応答を返すため、 fetchmail が間違って「No mail」と報告
してしまうことがあります。
IMAP のコードでは、サーバ上の \Seen の有無を使って メッセージが新しいかどうかを決めていま
す。 Unix の場合、fetchmail は IMAP サーバがメールユーザエージェントが設定した BSD 形式の
Status フラグに注目し、 適当な時にこれらを使って \Seen フラグを設定することを期待します。
これは IMAP の RFC の仕様にはありませんが、 我々が知る限りの Unix 用 IMAP サーバは全てこれ
を行います。 これを行わないサーバでつまずいたときには、 ホスト上の既読のメッセージが サー
バには新しく見えると言った症状が現われるでしょう。 この場合 (あまり起こりませんが) に
は、fetchmail --keep で 取得したメッセージだけが消されず、かつ既読の印が付けられます。
ETRN と ODMR モードでは、fetchmail は実際にはメールを取得しません。 その代わりに、サーバの
SMTP リスナに対して、 クライアントに SMTP 経由のキューのフラッシュを開始するように指示しま
す。 したがって、未配送のメッセージしか送りません。
スパムフィルタリング
SMTP リスナの多くでは、指定したドメインから送られてくる不要なメールを ブロックする「スパム
フィルタ (spam filter)」を管理者が設定できます。 この機能を呼び出す MAIL FROM あるいは
DATA 行は、 (残念なことに) リスナによって異なる SMTP の応答を引き出します。
最近のバージョンの sendmail はエラーコード 571 を返します。 この返し値は RFC1893 によって
"Delivery not authorized, message refused" として与えられています。
RFC821 から置き換えられた現在のドラフトによると、 このような状況で返すべき正しい値は、 550
"Requested action not taken: mailbox unavailable" とされています (このドラフトでは "[E.g.,
mailbox not found, no access, or command rejected for policy reasons]." を追加していま
す)。
exim という MTA は 501 "Syntax error in parameters or arguments" を返しますが、 これはもう
すぐ 550 に変更されます。
postfix という MTA はスパム拒否の応答として 554 を返します。
fetchmail のコードは応答のリストのいずれかに該当するメッセージを 認識・破棄します。 このリ
ストはデフォルトでは [571, 550, 501, 554] ですが、 `antispam' オプションを使って設定するこ
とができます。 fetchmail がメールを破棄してしまう状況は 3 つしか ありませんが、これはその
うちの 1 つです (残りは後述の 552, 553 エラーの場合と、 マルチドロップされたメッセージで
既に処理されているメッセージ ID を持つものを破棄する場合です)。
fetchmail が IMAP サーバからメールを取得する場合に antispam の応答が検出されると、
antispam ヘッダを取得した後、メッセージ本体を読むことなく 即座にメッセージを拒否します。
したがって、spam メッセージの本体をダウンロードする分の 課金を支払うことはありません。
spambounce オプションが有効になっている場合に、 メールがスパム防御を受けると、差出人にメー
ルを受け取らなかったことを知らせる RFC1892 の差戻しメッセージが送られます。
SMTP/ESMTP のエラー処理
先程説明したスパム防御以外にも、 fetchmail は以下の SMTP/ESMTP のエラー応答に対して特殊な
動作を行います:
452 (システムのディスクが不十分です)
後で取得できるようにサーバのメールボックスにメッセージを残します。
552 (メッセージが固定の最大メッセージサイズを越えました)
サーバからメッセージを削除します。差出人に差戻しメールを送ります。
553 (送信ドメインが不正です)
サーバからメッセージを削除します。差出人に差戻しメールを送ります。
他のエラーでは、差出人に差戻しメールが送られます。
実行制御ファイル
fetchmail を設定する好ましい方法は、 .fetchmailrc をホームディレクトリに作成することです
(これはテキストエディタで直接行なうこともできますし、 fetchmailconf を使って対話的に行なう
こともできます)。 コマンドライン引き数と、このファイル中の引き数が重なっている場合には、
コマンドライン引き数の方が優先されます。
パスワードの機密を守るため、--version オプションが有効でない場合には、 ~/.fetchmailrc の
パーミッションは 600 (u=rw,g=,o=) でなければなりません。 600 以外の場合には、 fetchmail
は、エラー出力を行って終了します。
fetchmail が引き数なしで実行される場合、.fetchmailrc ファイルは実行される コマンドのリスト
として読むことができます。
実行制御の記法
コメントは '#' で始まり、その行の最後まで続きます。 そうでない場合、このファイルは フリー
フォーマットかつトークン指向の文法で書かれた、 一連のサーバエントリか動作全体のオプション
の記述で構成されます。
トークンには 4 種類あります: すなわち、文法キーワード、数字 (つまり10進数を並べたもの)、
クォートされていない文字列、クォートされた文字列です。 クォートされた文字列はダブルクォー
トで囲まれ、空白文字を含むことができます (クォートされた数値は文字列として扱われます)。
クォートされていない文字列は、空白で区切られる任意のトークンであり、 数値やクォートされた
文字列でなく、 特殊文字 `,', `;', `:', `=' も含まないものです。
任意の数の空白文字はサーバエントリ中のトークンを区切りますが、 それ以外には無視されます。
標準の C 言語形式のエスケープ文字 (\n, \t, \b, 8進数, 16進数) を用いて 表示不可能な文字列
や文字列の区切り文字を文字列中に埋め込むことができます。
各サーバエントリは、キーワード `poll' または `skip'、 これに続くサーバ名、その後に続くサー
バオプション、 さらにその後に続く任意の数のユーザ記述から構成されます。 注意: 一番起こしや
すい文法エラーの原因は、 ユーザオプションとサーバオプションを混ぜてしまうことです。
後方互換性のため、キーワード `server' は `poll' と同義になります。
英語に似せるため、ノイズワード `and', `with', `has', `wants', `options' を エントリ中の任
意の場所で使うことができます。 これらは無視されますが、エントリがずっと読みやすくなりま
す。 区切り文字 ':', ';', ',' も同じく無視されます。
poll 対 skip
`poll' を指定すると、fetchmail が引き数なしで実行した時、 このホストへの問い合わせが行われ
ます。 `skip' を指定すると、コマンドラインで明示的に指定しない限り fetchmail はこのホスト
にポーリングを行いません。 (`skip' を使うと、テスト用エントリで安全に実験を行なうことや、
一時的に落ちているホスト用のエントリを簡単に無効にすることができます。)
キーワード/オプションのまとめ
以下は正式なオプションです。 大括弧 ([]) で括られているキーワードサフィックスは省略可能で
す。 コマンドラインオプションに対応するものの後には、 `-' と適切なオプション文字がありま
す。
正式な動作全体のオプションを以下に示します:
キーワード オプション 機能
────────────────────────────────────────────────────────────────────
set daemon バックグラウンドでのポーリング間隔
を秒数で設定します。
set postmaster 最終的なメール受取人の名前を指定し
ます。
set no bouncemail 送信者ではなく、postmaster にエ
ラーメールを送ります。
set no spambounce スパム防御を受けたときに差戻しメー
ルを送ります。
set logfile エラーメッセージと状態メッセージを
書き込むファイル名
set idfile UID リストを格納するファイル名。
set syslog syslog(3) を使ったエラーのログ取得
を行います。
set nosyslog syslog(3) を使ったエラーのログ取得
を止めます。
set properties fetchmail が無視する文字列の値 (拡
張スクリプトが使うことがありま
す)。
以下の正式なサーバオプションを示します:
キーワード オプション 機能
─────────────────────────────────────────────────────────────────
via メールサーバの DNS 名を指定しま
す。 これは poll 名を上書きしま
す。
proto[col] -p プロトコルを指定します (大文字・小
文字は関係ありません): POP2, POP3,
IMAP, APOP, KPOP。
local[domains] ローカルとして扱うドメインを指定し
ます。
port -P TCP/IP のサービスポートを指定しま
す。
auth[enticate] 認証のタイプを設定します (デフォル
ト値は `password')。
timeout -t サーバが動作していない時のタイムア
ウト値を秒数で指定します (デフォル
ト値は 300)。
envelope -E エンベロープアドレスのヘッダ名を指
定します。
no envelope エンベロープアドレスの検索を無効に
します。
qvirtual -Q ユーザ名から取り除く、qmail のバー
チャルドメインのプレフィックス。
aka メールサーバの別の DNS 名
interface -I サーバへのポーリングを行うためには
立ち上がっていなければならない IP
インタフェースを指定します。
monitor -M 動作を監視する IP アドレスを指定し
ます。
plugin サーバ接続を確立するためのコマンド
を指定します。
plugout リスナ接続を確立するためのコマンド
を指定します。
dns マルチドロップ用の DNS 参照を有効
にします (デフォルト)。
no dns マルチドロップ用の DNS 参照を無効
にします。
checkalias マルチドロップのために IP アドレス
による比較を行います。
no checkalias マルチドロップのために名前による比
較を行います (デフォルト)。
uidl -U POP3 で必ずクライアント側で UIDL
を使うようにします。
no uidl POP3 での UIDL の使用を止めます
(デフォルト)。
interval このサイトだけを N ポーリングサイ
クル毎にチェックします。 N は数値
の引き数です。
netsec IPsec セキュリティオプション要求を
渡します。
principal Kerberos 認証の principal を設定し
ます (imap と kerberos の場合にの
み有効です)。
正式なユーザオプションを以下に示します:
キーワード オプション 機能
────────────────────────────────────────────────────────────────
user[name] -u リモートのユーザ名を設定します
(name の後に `here' があると、ロー
カルのユーザ名です)。
is ローカルとリモートのユーザ名を繋ぎ
ます。
to ローカルとリモートのユーザ名を繋ぎ
ます。
pass[word] リモートアカウントのパスワードを指
定します。
ssl SSL による暗号化を使い、 指定され
た基本プロトコルを使ってサーバと接
続します。
sslcert クライアント側の公開 SSL 証明書を
指定します。
sslkey クライアント側の秘密 SSL 鍵を指定
します。
sslproto 接続のために ssl プロトコルを使わ
せます。
folder -r 問い合わせをするリモートのフォルダ
を指定します。
smtphost -S 転送先の SMTP ホスト (群) を指定し
ます。
fetchdomains メールを取得するドメインを指定しま
す。
smtpaddress -D RCPT TO 行に書くドメインを指定しま
す。
smtpname RCPT TO 行に書くユーザとドメインを
指定します。
antispam -Z スパム防御と解釈される SMTP の返し
値を指定します。
mda -m ローカルの配送に使う MDA を指定し
ます。
bsmtp -o 追加する BSMTP バッチファイルを指
定します。
preconnect それぞれの接続の前に実行するコマン
ド。
postconnect それぞれの接続の後に実行するコマン
ド。
keep -k 既読のメッセージをサーバから削除し
ません。
flush -F 問い合わせの前に既読のメッセージを
全てフラッシュします。
fetchall -a 既読・未読にかかわらず全てのメッ
セージを取得します。
rewrite リプライのために目的アドレスを書き
換えます (デフォルト)。
stripcr 行末からキャリッジリターン文字を取
り除きます。
forcecr 行末にキャリッジリターン文字を強制
します。
pass8bits ESMTP リスナに対し、BODY=8BITMIME
を強制します。
dropstatus やってくるメールから Status 行と
X-Mozilla-Status 行を取り除きま
す。
dropdelivered やってくるメールから Delivered-To
行を取り除きます。
mimedecode quoted-printable を 8ビットの MIME
形式のメッセージに変換します。
idle 各ポーリングの後、新しいメッセージ
を待つアイドル時間 (IMAP 専用)。
no keep -K 既読のメッセージをサーバから削除し
ます (デフォルト)。
no flush 問い合わせの前に既読メッセージ全て
はフラッシュしません (デフォル
ト)。
no fetchall 新規メッセージだけを取得します (デ
フォルト)。
no rewrite ヘッダを書き換えません。
no stripcr キャリッジリターン文字を取り除きま
せん (デフォルト)。
no forcecr 行末にはキャリッジリターン文字を強
制しません (デフォルト)。
no pass8bits ESMTP リスナに BODY=8BITMIME を強
制しません (デフォルト)。
no dropstatus Status ヘッダを捨てません (デフォ
ルト)。
no mimedecode quoted-printable を 8 ビット MIME
形式の メッセージには変換しません
(デフォルト)。
limit -l メッセージのサイズの上限を設定しま
す。
warnings -w メッセージサイズに関する警告の時間
間隔を設定します。
batchlimit -b 1 回の接続で転送するする最大メッ
セージ数。
fetchlimit -B 1 回の接続で取得する最大メッセージ
数。
expunge -e 何回目のメッセージごとに削除を実行
するかを指定します (IMAP と POP3
専用)。
tracepolls ポーリングトレース情報を Received
ヘッダに追加します。
properties fetchmail が無視する文字列値 (拡張
スクリプトで使うことができます)。
ユーザオプションは全てサーバオプションより後でなければいけません。
.fetchmailrc においては、`envelope' 文字列引き数の前に、 (空白で区切って) 数値を置くこと
ができます。 この数字が指定された場合、この値はこのようなヘッダを飛ばす数です (つまり、こ
の引き数に 1 を指定すると、 与えられたタイプの 2 番目のヘッダが選択されます)。 これは、ISP
のローカルの配送エージェントが付けた 偽の Received ヘッダを無視する時に便利です。
オプションスイッチに対応しないキーワード
`folder' と `smtphost' オプションには (同等のコマンドラインオプションとは異なり)、 空白区
切りまたはコンマ区切りの名前のリストを続けることができます。
全てのオプションは、見た通りのコマンドライン引き数に対応しますが、 以下のものはこれに該当
しません: `via', `interval', `aka', `is', `to', `dns'/`no dns', `checkalias'/`no
checkalias', `password', `preconnect', `postconnect', `localdomains', `stripcr'/`no
stripcr', `forcecr'/`no forcecr', `pass8bits'/`no pass8bits' `dropstatus/no dropstatus',
`dropdelivered/no dropdelivered', `mimedecode/no mimedecode', `idle/no idle', `no
envelope'.
`via' オプションは 同じサイトを指す複数の設定を使うためのものです。 これがある場合、文字列
引き数は問い合わせ先の メールサーバの実際の DNS 名として扱われます。 これは poll 引き数を
上書きし、これを設定を区別する単なるラベル (例えば、このホストを明示的に指定する時にコマン
ドラインで指定するもの) にすることができます。
`interval' オプション (数値の引き数を取ります) を使うと、 基本的なポーリング間隔より少ない
頻度で サーバにポーリングを行わせることができます。 `interval N' を指定すると、このオプ
ションが割り当てられた サーバに対する問い合わせは N 回ごとのポーリング間隔でしか行われませ
ん。
`is' または `to' キーワードは、その後に続くローカル (クライアント) 名 (または、= で区切ら
れるサーバ名からクライアント名へのマッピング) を エントリ中のメールサーバのユーザ名と関連
付けます。 is/to のリストの最後の名前に `*' があれば、認識されない名前もそのまま通します。
1 つのローカル名を使って、クライアントマシンでのユーザ名が メールサーバ上の名前と異なる時
に、 メールのリダイレクトをサポートすることができます。 ローカル名が一つしかないときは、
メッセージの Received, To, Cc, Bcc ヘッダに関らず、 メールはローカルのユーザ名宛に転送され
ます。 この場合には、 fetchmail は DNS の参照を行いません。
ローカル名 (または名前マッピング) が複数ある時には、 fetchmail のコードは取得したメールの
Received, To, Cc, Bcc ヘッダを参照します (これが「マルチドロップモード (multidrop
mode)」です)。 fetchmail は poll 名、`via', `aka', `localdomains' オプションの いずれかに
マッチする、ホスト部分を持つアドレスを探し、 また DNS で調べるとメールサーバのエイリアスで
あるホスト名部分も通常は探します。 アドレスのマッチングの処理方法の詳しい内容については、
`dns', `checkalias', `localdomains', `aka' の説明を参照してください。
fetchmail がメールサーバのユーザ名にも ローカルドメインにもマッチさせられない場合に
は、メールは差し戻されます。 このメールは通常、差出人に戻されますが、 `nobounce' オプショ
ンが有効ならば、これは postmaster に送られます (次に、これはデフォルトで fetchmail を呼び
出したユーザになります)。
`dns' オプション (通常は有効) は、マルチドロップメールボックスから取り出した アドレスを
チェックする方法を制御します。 このオプションが有効の時には、DNS を使った参照を行なうこと
により、 `aka' または `localdomains' の宣言にマッチしないホストそれぞれのアドレスを チェッ
クするロジックが有効になります。 メールサーバのユーザ名が、 マッチするホスト名部分に割り当
てられていることが認識された時、 そのローカルマッピングがローカルの受信者のリストに追加さ
れます。
`checkalias' オプション (通常は無効) は、 マルチドロップモードの `dns' キーワードが実行し
た検出結果を拡張し、 エイリアスを使ってポーリングされるものの、 自分自身を識別するにはカノ
ニカルな名前 (canonical name) を用いる リモートの MTA をうまく扱う方法を提供します。 この
ようなサーバがポーリングされたときは、 envelope アドレスが展開されたことのチェックは失敗
し、 fetchmail は To/Cc/Bcc ヘッダを使った配送に戻ります (後述の「ヘッダ対 envelope アドレ
ス」を参照してください)。 このオプションを指定すると、 fetchmail に対する、 poll 名とリ
モートの MTA が使う名前の両方に関係する全ての IP アドレスを取得し、 これらの IP アドレスの
比較を行うことの指示になります。 これは、リモートサーバのカノニカルな名前が頻繁に変わる状
況で役に立ちます。 これを使わなければ、実行制御ファイルを変更する必要があります。 実行制御
ファイルで `no dns' が指定された場合は、`checkalias' は無効です。
`aka' オプションはマルチドロップメールボックスと一緒に使うためのものです。 このオプション
を使うと、サーバの DNS 的な別名のリストを 予め宣言しておくことができます。 これは、速度と
容量のトレードオフを可能にする、最適化のためのハックです。 マルチドロップメールボックスを
処理している間に、 fetchmail がメッセージのヘッダを使ったメールサーバの名前の検索をあきら
めた時、 予め宣言してある共通の名前を使うと、DNS を参照するはめにならないで済みます。
`aka' の引き数として与えた名前は、 拡張子としてマッチされる点に注意してください -- 例えば
`aka netaxs.com' を指定した場合、 単に netaxs.com という名前のホストにはマッチしませんが、
pop3.netaxs.com や mail.netaxs.com といった `.netaxs.com' で終る任意のホスト名にマッチしま
す。
`localdomains' オプションを使うと、ローカルであると fetchmail が判断する ドメインのリスト
を宣言することができます。 fetchmail がマルチドロップモードでアドレス行を展開し、 かつ後に
続くホスト名の部分が宣言されたローカルドメインにマッチする時、 そのアドレスは変更されずに
リスナまたは MDA に渡されます (ローカル名マッピングは適用されません)。
`localdomains' を使っている場合には、 `no envelope' も指定する必要があるかもしれません。
このオプションは、fetchmail の通常の、 Received 行や X-Envelope-To ヘッダ、 あるいは以前に
`envelope' で設定されたヘッダの いずれかから envelope アドレスを推定しようとする動作を無効
にします。 デフォルトのエントリ中で `no envelope' を設定した場合、 `envelope <string>' を
用いて個別エントリ中でこれを取り消すことが可能です。 特別な場合として、`envelope
"Received"' で Received 行の展開の デフォルトの動作が復元されます。
password オプションは文字列の引き数を必要とします。 この文字列はエントリのサーバで使うパス
ワードです。
`preconnect' キーワードを使うと、 fetchmail がメールサーバへの接続を確立する直前に毎回実行
する シェルコマンドを指定することができます。 これは、 ssh(1) に補助させて安全な POP 接続
の設定をしようとする時に役に立つかもしれません。 コマンドがゼロでないステータスを返した場
合、 そのメールサーバへのポーリングは異常終了します。
同様に、`postconnect' キーワードを使うと、メールサーバへの接続が切れた 直後に毎回実行する
シェルコマンドを指定することができます。
`forcecr' オプションは、LF だけで終わる行を転送の前に CRLF で終わるようにするかどうかを制
御します。 厳密に言うと RFC821 はこれを要求しているのですが、 これを必須としている MTA は
ほとんどないので、 このオプションは通常は無効になっています (このような MTA で特に使われて
いるのは qmail だけで、 書き込み時にこれを行います)。
`stripcr' オプションは、取得したメールを転送する前に キャリッジリターン文字を取り除くかど
うかを制御します。 通常はこれをセットする必要はありません。 なぜなら、MDA が宣言されている
ときには、 これはデフォルトで「オン」(CR 削除が有効) となり、 SMTP 経由で転送されるときに
は「オフ」(CR 削除が無効) となるからです。 `stripcr' と `forcecr' が両方ともオンなら
ば、`stripcr' が優先されます。
`pass8bits' は、何にでも "Content-Transfer-Encoding: 7bit" を付けてくる 馬鹿な Microsoft
のメーラをうまく扱うために存在します。 このオプションが無効 (デフォルト) で、かつこのヘッ
ダが存在すると、 fetchmail は ESMTP 機能を持つリスナに対して BODY=7BIT を宣言します。 実際
には 8-bit ISO や KOI-8 の文字集合を使っているメッセージの場合、 これは問題を起こします。
これらの文字は上位ビットが全て落とされてしまうため、 文字化けしてしまいます。 `pass8bits'
がオンであれば、 fetchmail は ESMTP 機能を持つリスナ全てに対して必ず BODY=8BITMIME を宣言
します。 リスナが 8 ビットクリーンであれば (最近のめぼしいものは全部そうです)、 たぶんうま
くいくでしょう。
`dropstatus' オプションは、取得したメール中の空でない Status 行と X-Mozilla-Status 行を残
す (デフォルト) か破棄するかを制御します。 これらを残すと、お使いの MUA で (もしあれば) ど
のメッセージがサーバ上で既読の印が付けられているかを知ることができます。 一方、この動作は
新着メール通知プログラムの一部を混乱させることがあります。 これらのプログラムは、 Status
行が付いているものは全て既読と想定するのです。 (注意: 一部のバグっぽい POP サーバが付ける
空の Status 行は無条件に削除されます。)
`dropdelivered' オプションは、取得したメール中の Delivered-To ヘッダを残す (デフォルト) か
破棄するかを制御します。 このヘッダは、メールサーバ Qmail と Postfix が ループを防止するた
めに使用していますが、 同じドメイン内でメールサーバを「ミラー」しようとする場合は邪魔にな
ります。 このオプションは、注意して使用して下さい。
`mimedecode' オプションは、quoted-printable エンコーディングを用いている MIME メッセージを
純粋な 8 ビットデータに自動的に変換するかどうかを制御します。 ESMTP 機能を持ち、8 ビットク
リーンなリスナ (これには sendmail などの有名な MTA の大部分が含まれます) に メールを配送す
る場合には、 このオプションを使うと quoted-printable で書かれた メッセージヘッダとデータは
自動的に 8 ビットデータに変換され、 メールを読むときに理解しやすくなります。 お使いの電子
メールプログラムが MIME メッセージを扱えるならば、 このオプションは必要ありません。
mimedecode オプションはデフォルトで無効になっています。 なぜなら、ヘッダに対して RFC2047
の変換を行うと文字集合の情報が消えてしまい、 ヘッダのエンコーディングが本文のエンコーディ
ングと異なる場合に 好ましくない結果になるからです。
`idle' オプションは IMAP サーバが RFC2177 IDLE コマンド拡張を サポートしている場合にのみ使
用できます。 このオプションが設定されていて、 かつ IDLE コマンドをサポートしていることを
fetchmail が検知した場合、 ポーリングの終了毎に IDLE コマンドが発行されます。 このコマンド
を使うことで、 IMAP サーバに接続をオープンに保持させ、 新しいメールが来たことをクライアン
トに通知させます。 頻繁にポーリングを行う必要がある場合、 IDLE コマンドは、TCP/IP 接続とロ
グイン/ログアウトシーケンスをなくすことで、 バンド幅を押えることができます。 一方で、IDLE
接続は fetchmail のほとんどの時間を占めてしまいます。 なぜなら、IDLE コマンドは接続を切ら
ず、 サーバが IDLE をタイムアウトしない限り 別のプールが起こることを許可してしまうためで
す。 複数のフォルダがある場合も動作せず、 最初のフォルダのみがポーリングされます。
`properties' オプションは拡張のための機構です。 これは文字列の引き数を取ります
が、fetchmail 自身はこれを無視します。 この文字列引き数を使って、 設定情報を必要とするスク
リプトのための情報を保持することができます。 特に、`--configdump' オプションの出力は、 そ
のまま Python スクリプトとして利用できる、 ユーザエントリに関連するプロパティとなります。
その他の実行制御オプション
`here' と `there' は、英語と同じような意味で使える便利な単語です。 通常 `user eric is esr'
は、リモートユーザ `eric' 宛のメールが `esr' 宛に配達されるという意味です。 しかし、`user
eric there is esr here' と書くことでもっと分かりやすくしたり、 `user esr here is eric
there' と書いて意味を反対にすることができます。
`protocol' キーワードで使用できる有効なプロトコル識別子を以下に示します:
auto (または AUTO)
pop2 (または POP2)
pop3 (または POP3)
sdps (または SDPS)
imap (または IMAP)
apop (または APOP)
kpop (または KPOP)
有効な認証のタイプは `any', `password', `kerberos', 'kerberos_v5', `gssapi', `cram-md5',
`otp', `ntlm', `ssh` です。 `password' タイプは普通のパスワード送信による認証を指定します
(パスワードはプレーンテキストのこともあれば、 APOP のようにプロトコル固有の暗号化がされて
いることもあります)。 `kerberos' を指定するとパスワード認証は行われず、 fetchmail はそれぞ
れの問い合わせの開始時に Kerberos のチケットを取得し、 パスワードとして任意の文字列を送信
しようとします。 `gssapi' を指定すると fetchmail は GSSAPI 認証を使います。 さらに詳しい情
報については `auth' キーワードの説明を参照してください。
`kpop' を指定すると、1109 番ポート上で Kerberos V4 認証を使う POP3 プロトコルが設定されま
す。 これらのデフォルト値は、後に現われるオプションによって上書きされます。
グローバルオプションを指定する文は現在 4 つあります。 `set logfile' の後に文字列を記述した
ものは、 --logfile オプションの指定と同じグローバルな設定を行います。 コマンドラインの
--logfile はこれを上書きします。 また `set daemon' は、--daemon オプションと同じように
ポーリング間隔を設定します。 これはコマンドラインの --daemon オプションで上書きすることが
できます。 特例として、--daemon 0 を使って、 強制的にフォアグラウンド動作をさせることがで
きます。 `set postmater' 文は、ローカルで一致するものがない場合に マルチドロップメールがデ
フォルトで送られるアドレスを設定します。 最後に、`set syslog' を指定するとログメッセージが
syslogd(8) に 送られるようになります。
RFC 822 との相互作用
メッセージの送信アドレスを決めようとするとき、 fetchmail は以下の順でヘッダを参照して行き
ます:
Return-Path:
Resent-Sender: (@ または ! を含んでいない場合は無視される)
Sender: (@ または ! を含んでいない場合は無視される)
Resent-From:
From:
Reply-To:
Apparently-From:
送信アドレスはログの記録と、 SMTP に転送する時の MAIL FROM アドレスの設定のために使われま
す。 この順序はマルチドロップモードでメーリングリストの受信を うまく処理するためのもので
す。 その目的は、ローカルアドレスが存在しない場合に、 差し戻しメッセージがメールを出した人
やメーリングリスト本体にむやみに返されず、 メーリングリストの管理者に届くようにすることで
す (こちらの方がまだマシです)。
マルチドロップモードでは、宛先のヘッダは以下のように処理されます: 最初に、fetchmail は
Received: ヘッダ (あるいは、`envelope' で指定した任意のヘッダ) を探し、 ローカルの受信者ア
ドレスを決めます。 もしメールが複数の受信者に宛てたものであれば、 Received は受信者のアド
レスという点では全く情報を持っていないでしょう。
次に、fetchmail は Resent-To:, Resent-Cc:, Resent-Bcc: 行を探します。 これらのヘッダが存在
する場合、これらには最終的な受信者が書かれており、 対になっている To:/Cc:/Bcc: よりも優先
されます。 もし Resent-* 行が存在しなければ、 To:, Cc:, Bcc:, Apparently-To: 行が探されま
す。 (Resent-To: があると、To: アドレスが指している人物は 既にそのメールのコピーを受け取っ
ているものと考えられます。)
設定例
以下の多くの例では、password 宣言があるが、 これは主に例示のためのものです。 アカウント/パ
スワードのペアを $HOME/.netrc ファイルに 隠しておくことをお勧めします。 このファイルは
fetchmail だけでなく ftp(1) やその他のプログラムでも 使うことができます。
基本フォーマットを以下に示します:
poll SERVERNAME protocol PROTOCOL username NAME password PASSWORD
例:
poll pop.provider.net protocol pop3 username "jsmith" password "secret1"
省略形を使えるものもあります:
poll pop.provider.net proto pop3 user "jsmith" password "secret1"
複数のサーバを並べることができます:
poll pop.provider.net proto pop3 user "jsmith" pass "secret1"
poll other.provider.net proto pop2 user "John.Smith" pass "My^Hat"
上記の 2 つの例について、空白文字とノイズワードをいくつか増やしたもの を示します:
poll pop.provider.net proto pop3
user "jsmith", with password secret1, is "jsmith" here;
poll other.provider.net proto pop2:
user "John.Smith", with password "My^Hat", is "John.Smith" here;
こう書いた方がずっと読みやすいですが、処理の手間はそんなにかかりません (起動時に一度行われ
るだけです)。
パラメータ文字列に空白文字を含める必要がある場合には、 文字列をダブルクォートで囲みましょ
う。 以下のような形です:
poll mail.provider.net with proto pop3:
user "jsmith" there has password "u can't krak this"
is jws here and wants mda "/bin/mail"
最初のサーバ記述では、名前の前にキーワード `poll' ではなく、 キーワード`defaults' を置くこ
とができます。 このようなレコードは、 全ての問い合わせで使われるデフォルト値として解釈され
ます。 これは個別のサーバ記述で上書きすることができます。 つまり、以下のように書くことがで
きます:
defaults proto pop3
user "jsmith"
poll pop.provider.net
pass "secret1"
poll mail.provider.net
user "jjsmith" there has password "secret2"
サーバごとに複数のユーザを指定することもできます (これが役に立つのは多分、 root がデーモン
モードで fetchmail を実行するときだけでしょう)。 1 人のユーザ記述は `user' キーワードで始
まり、 ユーザエントリが複数ある場合には、 このキーワードがユーザ指定それぞれに含まれていな
ければなりません。 以下に例を示します:
poll pop.provider.net proto pop3 port 3111
user "jsmith" with pass "secret1" is "smith" here
user jones with pass "secret2" is "jjones" here keep
これは、ローカルのユーザ名 `smith' を the pop.provider.net のユーザ名 `jsmith' に対応さ
せ、 ローカルのユーザ名 `jjones' を pop.provider.net のユーザ名 `jones' に対応させます。
`jones' のメールはダウンロード後もサーバーに残されます。
マルチドロップメールボックス用の取得を行う簡単な設定がどんな感じかを 以下に示します:
poll pop.provider.net:
user maildrop with pass secret1 to golux 'hurkle'='happy' snark here
これは、サーバ上のアカウント `maildrop' がマルチドロップボックスであり、 その中のメッセー
ジはサーバのユーザ名 `golux', `hurkle', `snark' に対して 展開するという指定です。 これはさ
らに、`golux' と `snark' はクライアントでも サーバと同じ名前を持つけれど、 サーバのユーザ
`hurkle' 宛のメールは クライアントのユーザ `happy' に配送することも指定します。
別の種類のマルチドロップ接続の例を示します:
poll pop.provider.net localdomains loonytoons.org toons.org:
user maildrop with pass secret1 to * here
これも、サーバ上のアカウント `maildrop' が マルチドロップボックスであることを指定します。
これは fetchmail に対し、 loonytoons.org や toons.org ドメイン内のアドレス全て
(`joe@daffy.loonytoons.org' のようなサブドメインのアドレスも含みます) は 変更せずにローカ
ルの SMTP リスナへ渡すことを指示します。 これを行うときにはメールのループには注意してくだ
さい!
ssh と plugin オプションを用いた一つの設定例を示します。 問い合わせは、ssh を経由し
て、imapd の標準入力と標準出力で直接行われます。 この設定では IMAP 認証が飛ばされることに
注意して下さい。
poll mailhost.net with proto imap:
plugin "ssh %h /usr/sbin/imapd" auth ssh;
user esr is esr here
マルチドロップメールボックスの良い使い方と良くない使い方
ローカルの受信者を複数持つ機能は注意して使ってください。 痛い目を見るかもしれません。 ETRN
と ODMR モードではマルチドロップ機能は全く使えない点に注意してください。
また、マルチドロップモードでは複製されたメールは 消される点にも注意してください。 あるメー
ルが複製されていると判断されるのは、 直前のメッセージと同じメッセージ ID が付いていて、 複
数のアドレスが指定されている場合です。 このようにメッセージが連続することは、 複数のユーザ
宛の 1 通のメールのコピーが 1 つのマルチドロップメールボックスに配送された時に起こります。
ヘッダ対 envelope アドレス
基本的な問題は、メールサーバに複数のユーザのメールを 1 つのメールドロップへ投げさせること
により、 それぞれのメールが実際に届けられていたユーザに関する、 もしかすると非常に重要かも
しれない情報 (`envelope アドレス', RFC822 の To/Cc/Bcc ヘッダとは対立するものです) を 捨て
てしまう可能性があることです。 この `envelope アドレス' は、 メールを適切に振り分けるため
に必要なアドレスです。
fetchmail が envelope アドレスを推定できることも時々あります。 メールサーバの MTA が
sendmail であり、メールの受信者が 1 人しかいない場合、MTA は envelope アドレスを Received
ヘッダに与える `by/for' の項を書いているでしょう。 しかし、これは他の MTA でも確実に動作す
るとは言えませんし、 複数の受信者がいる場合にも動作しません。 デフォルトでは、fetchmail は
これらの行で envelope アドレスを探します。 -E "Received" または `envelope Received' を指定
すると 動作をこのデフォルトに戻すことができます。
これを行う代わりに、一部の SMTP リスナやメールサーバは、 envelope アドレスのコピーを持つ
ヘッダを各メッセージに挿入します。 このヘッダは (存在するならば) `X-Envelope-To' のことが
よくあります。 -E オプションまたは `envelope' オプションを用いると、 fetchmail が想定する
ヘッダを変更することができます。 この種類の envelope ヘッダを書くと、(ブラインドコピーの受
信者も含めた) 全ての受信者の名前がメッセージ受信者に明らかになってしまいます。 したがっ
て、これをセキュリティ/プライバシーの問題であると 考えるシステム管理者もいます。
`X-Envelope-To' を少し変えたものが、 qmail がメールのループを避けるために追加する
`Delivered-To' ヘッダです。 これは、通常はユーザのドメインに マッチする文字列の前に、ユー
ザ名を置いたものであることが多いです。 このプレフィックスを取り除くには、 -Q または
`qvirtual' オプションを使います。
残念ながら、これらが両方ともうまく動作しないこともあります。 これらが全て失敗した場
合、fetchmail は To/Cc/Bcc ヘッダから出直して、 受信者のアドレスを決めなければなりません
が、これらのヘッダは信頼できません。 特に、メーリングリストのソフトウェアが リスト全体のア
ドレスしか To ヘッダに付けないでメールを送ることがよくあります。
fetchmail がローカルの受信者アドレスを推定できず、 かつ本来の受信者のアドレスが fetchmail
を実行したユーザ以外である場合、 メールは無くなってしまうでしょう。 これがマルチドロップ機
能を危険にしている要因です。
これに関連する問題は、メールのメッセージをブラインドコピーするとき、 Bcc 情報は envelope
アドレスとしてのみ伝えられるということです (X-Envelope ヘッダがなければ、fetchmail が読め
るヘッダには書かれません)。 したがって、メールサーバのホストが常に X-Envelope ヘッダあるい
はこれと 同等のヘッダをメールドロップに入れるメッセージに書くようになっていなければ、
fetchmail 経由でメールを取得するユーザ宛のブラインドコピーは失敗します。
マルチドロップメールボックスの良い使い方
ローカル名を複数使うことにより、fetchmail のクライアント側から メーリングリストを管理する
ことができます。 あなたのユーザ名が `esr' であり、自分宛のメールを受け取ることと (例えば)
"fetchmail-friends" という 名前のメーリングリストの管理を両方やりたいとします。 それか
ら、あなたのクライアントマシンで エイリアスのリストも管理したいものとします。
サーバでは、`fetchmail-friends' を `esr' に エイリアス設定することができます。 それか
ら、.fetchmailrc では `to esr fetchmail-friends here'を宣言します。 すると、`fetchmail-
friends' をローカルアドレスとして含んでいる メールが取得されたとき、 メーリングリストの名
前が SMTP リスナが見ている受信者のリストに追加されます。 したがって、エイリアスの展開は
ローカルで行われます。 必ず、`esr' を fetchmail-friends のローカルのエイリアス展開に含めて
ください。 さもないと、このメーリングリストだけが宛先になっている メールを絶対に見ることが
できません。 また、リスナの「自分にも」というオプションを必ずセットして (sendmail では
-oXm コマンドラインオプションか、OXm 宣言です)、 あなたが送ったメッセージのエイリアス展開
から あなたの名前が削除されないようにしてください。
しかし、このトリックに問題がないわけではありません。 あなたがローカル名として宣言して いな
いメーリングリストだけが宛先になっているメールが来ると、 その問題が明らかになるでしょう。
このようなメッセージのそれぞれには、 `X-Fetchmail-Warning' ヘッダが付いています。 このヘッ
ダは、fetchmail が受信者アドレス中で 有効なローカル名を見つけられなかったために生成される
ものです。 このようなメッセージは、デフォルトで (既に述べたように) fetchmail を実行してい
るローカルユーザに送られますが、 それが本当に正しい処置なのかをプログラム側から知る方法は
ありません。
マルチドロップメールボックスの良くない使い方
マルチドロップメールボックスと、デーモンモードで複数のユーザにサービスを行う fetchmail を
同時に使ってはいけません。 繰り返しますが、メーリングリストからのメールで問題が起こりま
す。 このようなメールには通常、受信者個人のアドレスが書かれていないのです。 fetchmail が
envelope アドレスを推定できなければ、このようなメールは fetchmail を実行したユーザ (root
であることが多いでしょう) にしか届きません。 また、ブラインドコピーの宛先になっているユー
ザはきっと、 このようなメールが全く読めないでしょう。
もし、 fetchmail を使って 1 つのメールドロップから POP や IMAP 経由で 複数ユーザ宛のメール
を取得しようと考えているならば、考え直してください (そして、前述のヘッダと envelope アドレ
スに関する セクションを読み直してください)。 メールは単にメールサーバのキューに入れてお
き、 fetchmail の ETRN や ODMR モードを使って定期的に SMTP での送信を行わせる方が賢いやり
かたでしょう (この場合はもちろん、メールサーバでのメールの有効期限よりも短い間隔で ポーリ
ングをしなければならないことになります)。 このような設定ができないのならば、UUCP による配
送を設定してみてください。
どうしてもこの目的でマルチドロップを使わなければならないのであれば、 fetchmail が参照でき
る envelope アドレスヘッダを メールサーバが書き込むように必ずしてください。 さもなく
ば、メールはきっと無くなってしまい、 あなたを呪うために帰ってくることになるでしょう。
マルチドロップのチェックの高速化
通常は、複数のユーザが宣言されているとき、 fetchmail は受信者アドレスを先程説明したように
展開し、 それぞれのホスト部分を DNSでチェックし、 これがメールサーバのエイリアスかどうかを
調べます。 そうであれば、「to ... here」宣言で記述された名前のマッピングが実行され、 メー
ルがローカルに配送されます。
これはとても安全ですが、非常に遅い方法です。 これを高速化するためには、 `aka' を使ってメー
ルサーバのエイリアスを予め宣言してください。 これらは DNS の参照を行う前にチェックされま
す。 aka のリストがメールサーバの DNS エイリアス (および、これを指す全ての MX 名) を 全て
含んでいることが確かであれば、`no dns' を宣言して DNS 参照を完全に止め、 aka リストに対し
てのみマッチングを行わせることができます。
終了コード
シェルスクリプト内で fetchmail をうまく使えるように、与えられた接続の間に起きたことを伝え
るための 終了コードが返されるようになっています。
fetchmail が返す終了コードを以下に示します:
0 1 つ以上のメッセージがうまく取得できた場合 (-c オプションを指定している時は、 取得
待ちのメールを見つけ、取得を行わなかった場合)。
1 取得待ちのメールが無かった場合。 (サーバ上に古いメールがまだあるけれど、 取得される
ものとして選ばれていなかった場合もあります。)
2 メール取得のためにソケットをオープンしようとしたときにエラーに出会った場合。 ソケッ
トが何かを知らなくても、心配には及びません。 これは単に「どうしようもないエラー」と
して扱ってください。 このエラーは fetchmail が使おうとしたプロトコルが
/etc/services にリストされていない場合にも起こります。
3 ユーザ認証のステップで失敗した場合。 これは通常、ユーザ ID、パスワード、 APOP ID の
指定が間違っていることを意味します。 これ以外の場合では、標準入力が端末に接続されて
いない状況で fetchmail を実行しようとしていて、 入力できなかったパスワードを入力す
るためのプロンプトが 出せないことを意味しています。
4 何らかの種類の致命的なプロトコルエラーが検出された場合。
5 fetchmail に与えた引き数に文法エラーがある場合。
6 実行制御ファイルのパーミッションが正しくない場合。
7 サーバからエラー状態が報告された場合。 サーバへの接続待ちで fetchmail がタイムアウ
トを起こした時にもこうなります。
8 クライアント側の排他エラーの場合。これは fetchmail が既に動作している別の fetchmail
を検出したか、検出に失敗したため fetchmail が動作しているかどうかはっきりしないこと
を意味します。
9 サーバが応答で "lock busy" を返したために、 ユーザ認証ステップが失敗した場合。
ちょっと待ってから再挑戦してください! このエラーはプロトコル全てに実装されているわ
けではないですし、 サーバ全てに実装されているわけでもありません。 このエラーがサー
バに実装されていない場合には、 このコードではなく "2" が返されます (前の項目を参照
してください)。 "lock busy" やこれに似たテキストで "lock" という語を含むものを応答
として返す、 qpopper や他のサーバと通信したときにこのコードが返されることがありま
す。
10 SMTP ポートのオープンやトランザクションを行おうとしている時に fetchmail の動作が失
敗した場合。
11 致命的な DNS のエラー。fetchmail が起動時に DNS の参照に失敗し、 その先を実行できな
かったときに起こります。
12 BSMTP のバッチファイルをオープンできなかった場合。
13 取得の制限によりポーリングが終了した (--fetchlimit オプションを参照)。
14 サーバがビジーであることを示します。
23 内部エラーの場合。標準エラー出力に出るメッセージを詳しく見てください。
fetchmail が複数のホストに問い合わせを行う場合、 いずれかの問い合わせでメールをうまく取得
できれば、 ステータス 0 が返されます。 そうでないに返されるエラーステータスは、 最後に問い
合わせを行ったホストのステータスとなります。
ファイル
~/.fetchmailrc
デフォルトの実行制御ファイル
~/.fetchids
ホストと前回の読んだメールのメッセージ ID を対応づける ファイルのデフォルトの位置
(UIDL コマンドをサポートしている、 RFC1725 準拠の最近の POP3 サーバでしか使うことがで
きません)。
~/.fetchmail.pid
多重実行を防ぐためのロックファイル (非 root モードの場合)。
~/.netrc
FTP の実行制御ファイル。(もしあるならば) 対話的にパスワードを求める前に、 最終的にパ
スワードが検索されるファイルです。
/var/run/fetchmail.pid
多重実行を防ぐためのロックファイル (root モード、Linux の場合)。
/etc/fetchmail.pid
多重実行を防ぐためのロックファイル (root モード、/var/run が無いシステムの場合)。
環境変数
環境変数 FETCHMAILUSER が設定されている場合、 エラー通知をメールで知らせるためのユーザ名と
して使われます (デフォルトではローカル名が使われます)。 この環境変数が設定されていない場
合、 環境変数 LOGNAME か USER の値が正しく設定されていれば (例えば、この値に対応する UID
がセッションのユーザ ID に一致する)、 その名前がデフォルトのローカル名として使われます。
これらの環境変数も設定されていない場合、 getpwuid(3) がセッション ID に対する パスワードエ
ントリを取得できなければいけません (このような手の込んだロジックは、 1 つのユーザ ID に複
数のユーザ名が対応する場合を うまく扱うために用意されています)。
環境変数 FETCHMAILHOME が 実際に存在する正しいディレクトリ名に設定されている場合、 ファイ
ル .fetchmailrc, .fetchids, .fetchmail.pid は、 起動したユーザのホームディレクトリではな
く、 この環境変数で指定したディレクトリに置かれます (ファイル名の先頭にあるドットは取り除
かれます)。 .netrc ファイルは、FETCHMAILHOME の設定に関係なく、 起動したユーザのホームディ
レクトリでロックされます。
シグナル
fetchmail デーモンが root 権限で動作している場合には、 SIGHUP によりスリープ状態から覚め、
skip 指定でないサーバ全てに対してポーリングを行います (これはシステムデーモンの普通の伝統
に従うものです)。
デーモンモード fetchmail が root 権限以外で動作している場合、 デーモンを起こすには SIGUSR1
を使います (logout による SIGHUP がデフォルトの動作をそのまま持ち、 fetchmail を kill する
かもしれないためです)。
バックグラウンドで fetchmail が動作しているときに、フォアグラウンドで fetchmail を実行する
と、上記のうち適切なデーモンが起こされます。
バグと既知の問題
mda オプションと plugin オプションは相性が良くありません。 MDA からエラー状態を取得するた
めには、 fetchmail は通常のシグナル処理を変更する必要があります。 このようにすると、ポーリ
ングサイクルが終るまで 死んだプラグインプロセスが破棄されません。 そして、ゾンビプロセスが
非常にたくさんできた場合は リソースの枯渇が起こってしまいます。 プラグインを使った MDA へ
の配送を行わないか、 大量のゾンビプロセスで溢れるかもしれないリスクを負うかのどちらかにな
ります。
マルチドロップモードで使われている RFC822 アドレスのパーザは、 技術的には正しいけれどおか
しな @-アドレスで詰まってしまうことがあります。 また、クォートと埋め込みコメントの使い方が
おかしいと、 パーザの動作がおかしくなりやすいです。
メッセージに複数の envelope ヘッダがある場合、 fetchmail には最後に処理されたヘッダしか見
えません。 これを回避するには、 envelope ヘッダの内容全てを 1 つのヘッダにまとめるフィルタ
(procmail, mailagent, maildrop に手順を指示すれば、 これはかなり簡単に行えます) をメール
サーバ側で使ってください。
プロトコルのうちのいくつかを使う場合には、 プログラムが暗号化されていないパスワードを メー
ルサーバまで TCP/IP 接続上で送る必要があります。 これは、パケットスニファ (packet sniffer)
や もっと高機能な監視ソフトウェアによって 名前とパスワードの組を盗まれる危険性の元となりま
す。 Linux と FreeBSD の場合、--interface オプションを使うと、 特定のローカルまたはリモー
トの IP アドレスを持つ 特定のインタフェースデバイスに対してのみ ポーリングが可能であるよう
に制限できますが、 その場合でも (a) どちらかのホストが 無差別モード (promiscuous mode) で
オープンできる ネットワークデバイスを持っているか、 (b) 間にあるネットワーク接続が盗聴可能
であれば盗聴は可能です。 パスワードを暗号化するだけでなく、全ての通信を暗号化するために
も、 ssh(1) トンネリングの使用をお勧めします。
mda オプションで %F, %T エスケープを使うとセキュリティホールができます。 なぜなら、これら
のエスケープは攻撃者が操作できるテキストを シェルコマンドに渡すからです。 シェル文字になる
可能性があるものは、実行の前に `_' に置換されます。 fetchmail は MDA を実行している間、
SUID により得ることができた権限を一時的に全て破棄するので、 このセキュリティホールはかなり
小さくなっています。 しかし、できるだけ安全にするために、 fetchmail をroot のアカウントか
ら実行するときには、 %F, %T を含むmda コマンドを使ってはいけません。
fetchmail における bouncemail と spambounce の出し方では、 ローカルホストの 25 番ポートで
SMTP 経由のメールが送れなければなりません。
このプロセスをバックグラウンドで実行している時に ~/.fetchmailrc を修正し、文法を間違ってし
まうと、 バックグラウンドのプロセスは何も言わずに終了してしまいます。 悪いことに、このプロ
グラムは何かを書き出して終了することができません。 なぜなら、syslog を有効にすべき否か
が、まだ分からないからです。
(設定を標準入力から読み込む) -f - オプションは、 プラグインオプションとは互換性がありませ
ん。
UIDL コードは一般的にあまり当てにならないもので、 行を飛ばした場合やエラーの場合に、コード
の状態を失いやすい傾向があります (そのため、古いメッセージが再度閲覧されてしまいます)。 こ
のような場合は、IMAP4 に乗り換えて下さい。
`principal' オプションは Kerberos IV しか扱わず、 Kerberos V は扱いません。
コメント、バグ報告、苦情の類は、fetchmail-friends メーリングリスト <fetchmail-
friends@lists.ccil.org> に送ってください。 HTML 版の FAQ が fetchmail のホームページにあり
ます。 http://www.tuxedo.org/~esr/fetchmail へ行くか、 `fetchmail' 関連のページを WWW で検
索してください。
著者
Eric S. Raymond <esr@snark.thyrsus.com>。 ここでは挙げられないほど多くの方々がコードやパッ
チを提供してくださいました。 このプログラムは Carl Harris <ceharris@mal.com> さん作の
popclient を基にしており、これを置き換えるものです。 内部的にはまったく異なるものになりま
したが、 インタフェース設計の一部については、 このご先祖様のものをそのまま引き継いでいま
す。
関連項目
mutt(1), elm(1), mail(1), sendmail(8), popd(8), imapd(8), netrc(5)
準拠している標準規約
SMTP/ESMTP:
RFC 821, RFC2821, RFC 1869, RFC 1652, RFC 1870, RFC1983, RFC 1985
mail:
RFC 822, RFC2822, RFC 1123, RFC 1892, RFC 1894
POP2:
RFC 937
POP3:
RFC 1081, RFC 1225, RFC 1460, RFC 1725, RFC1734, RFC 1939, RFC 1957, RFC2195, RFC
2449
APOP:
RFC 1460, RFC 1725, RFC 1939
RPOP:
RFC 1081, RFC 1225
IMAP2/IMAP2BIS:
RFC 1176, RFC 1732
IMAP4/IMAP4rev1:
RFC 1730, RFC 1731, RFC 1732, RFC 2060, RFC 2061, RFC 2195, RFC 2177, RFC 2683
ETRN:
RFC 1985
ODMR/ATRN:
RFC 2645
OTP: RFC 1938
LMTP:
RFC 2033
GSSAPI:
RFC 1508
fetchmail(1)