fetchmailのヘルプ・マニュアル
日本語 英語
fetchmail --help
man fetchmail
fetchmail(1) fetchmail(1)
名前
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 の動作はコマンドラインオプションと実行制御ファイル ~/.fetch-
mailrc で制御することができます。実行制御ファイルの文法は後のセクション
で 説明します (このファイルは fetchmailconf プログラムが編集します)。コ
マンドラインオプションは、 ~/.fetchmailrc での宣言を上書き指定します。
問い合わせは、コマンドラインのオプションの後に指定した全てのサーバに 対
し て行われます。コマンド行でサーバを指定していない場合には、 ~/.fetch-
mailrc ファイルの ‘poll’ エントリそれぞれに対して問い合わせが行われます
。
fetchmail は、スクリプトやパイプラインで使いやすいように、終了時に適切
な終了コードを返すようになっています。後述の「終了コード」セクション を
ご覧ください。
以 下 の オ プションで fetchmail の動作が変わります。一度うまく動作する
.fetchmailrc ファイルが設定できれば、その後はこれらのオプションを指定す
る必要はほとんどないでしょう。
ほ と んど全てのオプションには対応するキーワードがあり、これらは fetch-
mailrc ファイルで宣言することができます。
ここでは一部の特殊なオプションは説明しておらず、代わりに後述の「認証 」
と「デーモンモード」に関するセクションで説明しています。
一般設定のオプション
-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[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 send-
mail のリリース 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 を指定することができます。 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 接続が確立されると fetch-
mail はこの形式で署名を表示します。このオプションが指定される と
、サーバ・キーの署名を与えられた署名と比較します。一致しなかった
場合、接続は失敗します。これは経路の途中にいる人間が行う攻撃を阻
止できます。
配送制御オプション
-S , --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 , --antispam
(キーワード: 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 進数で引き数に取ります。
このサイズより大きいメッセージは取得されず、サーバ上に残されます
(フォアグラウンドのセッションでは、進行状況メッセージ で "over-
sized (サイズ超過)" であると知らされます)。メールの取得に使われ
るプロトコル (特に fetchall オプションを指定しない IMAP ま た は
POP3) によって未読の印を付けることができる場合、明示的に --limit
に 0 を指定すると、実行制御ファイルで設定した上限値を全て上書 き
します。このオプションは、電話料金が高くて変化もするという理由か
ら、メール取得の時間を厳しく制御する必要がある人のためのものです
。デーモンモードでは、サイズ超過の通知は呼び出しを行ったユーザに
対してメールで行われます (--warning オプションを参照)。このオ プ
ションは ETRN と ODMR では使えません。
-w <間隔>, --warnings <間隔>
( キーワード: warnings) 時間間隔を秒数で引き数に取ります。デーモ
ンモードで ‘limit’ オプションを付けて fetchmail を呼び出すと、こ
のオプションはサイズを超過しているメッセージに関する警告が呼び出
したユーザ (または ‘postmaster’ オプションで指定したユーザ) にメ
ールで送られる時間間隔を制御します。このような通知は常に、サイズ
を超過しているメッセージが見つかった最初のポーリングの終了時にメ
ールで送られます。その後は、警告時間間隔が経過するまで再通知は止
められます (これは、後に続く最初のポーリングの終了時に行わ れ ま
す)。
-b <最大数>, --batchlimit <最大数>
( キーワード: batchlimit) 接続をわざと止めてから再接続するまでに
SMTP 受信プログラムに送信するメッセージの最大数を指定します ( デ
フ ォ ル ト値は 0 で、これは無制限を表します)。明示的に --batch-
limit に 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 アドレス (またはアドレス範囲) を持つことを要求します。 fetch-
mail は 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) このオプションは、 fetchmail がメー ル の
envelope アドレスのコピーを運ぶと想定するヘッダを変更します。通
常これは ‘X-Envelope-To’ ですが、これは標準ヘッダではないので 、
実際には別のものになることがあります。後述のマルチドロップアドレ
ス処理に関する議論を参照してください。特殊な場合とし て 、‘enve-
lope "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@user-
host.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/~dug-
song/dsniff/ にある dsniff のようなツールを使うと特に) 簡単に可能である
こ とを知っておかなければなりません。自分のメールボックスのセキュリティ
を真剣に考えるなら、 ssh トンネル (下記の例を参照) をお勧めします。
デーモンモード
--daemon <間隔> または -d <間隔> を使うと fetchmail をデーモンモード で
実 行できます。引き数として、ポーリングの時間間隔を秒数で指定しなければ
なりません。
デーモンモードでは、 fetchmail は自分自身をバックグラウンドでずっと動作
さ せます。つまり、指定された各ホストへの問い合わせと、指定された時間の
スリープを繰り返します。
したがって、単に
fetchmail -d 900
を実行すると、 ~/.fetchmailrc に記述された全てのホスト ( キ ー ワ ー ド
‘skip’ で明示的に除外されたホストは除きます) に対して 15 分ごとに 1 回
ポーリングを行います。
‘set daemon ’ を ~/.fetchmailrc ファイルに書くことでポーリ ン
グ間隔を設定することが可能です。ここで、 は秒数を表す整数値で
す。これを行うと、コマンドラインオプションの --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 <ファイル名> オプションが使われているものとし て sys-
log(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’ になります。 postmas-
ter のユーザ名を空の文字列に設定すると、このようなメールは破棄されま す
。
--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’ が指定された 場 合 は 、‘check-
alias’ は無効です。
‘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 ’
を用いて個別エントリ中でこれを取り消すことが可能です。特別な場合とし て
、‘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 で (もしあれば) どのメッセージがサーバ上で既読の印
が 付けられているかを知ることができます。一方、この動作は新着メール通知
プログラムの一部を混乱させることがあります。これらのプログラムは、 Sta-
tus 行が付いているものは全て既読と想定するのです。 (注意: 一部のバグっ
ぽい POP サーバが付ける空の Status 行は無条件に削除されます。)
‘dropdelivered’ オプションは、取得したメール中の Delivered-To ヘッダ を
残 す (デフォルト) か破棄するかを制御します。このヘッダは、メールサーバ
Qmail と Postfix がループを防止するために使用していますが、同じドメイン
内 でメールサーバを「ミラー」しようとする場合は邪魔になります。このオプ
ションは、注意して使用して下さい。
‘mimedecode’ オプションは、quoted-printable エンコーディングを用いて い
る MIME メッセージを純粋な 8 ビットデータに自動的に変換するかどうかを制
御します。 ESMTP 機能を持ち、8 ビットクリーンなリスナ (これに は send-
mail などの有名な 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’ を指定すると fetch-
mail は 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-Enve-
lope ヘッダがなければ、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 メーリングリスト
に送ってください。 HTML 版の FAQ が
fetchmail のホームページにあります。 http://www.tuxedo.org/~esr/fetch-
mail へ行くか、 ‘fetchmail’ 関連のページを WWW で検索してください。
著者
Eric S. Raymond 。ここでは挙げられないほど多くの
方 々 が コ ードやパッチを提供してくださいました。このプログラムは Carl
Harris さん作の 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)