一般設定のオプション¶

-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 には以下のどれかを指定することができます:

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 エディタと一緒に使うためのものです。

実行制御の記法¶

コメントは '#' で始まり、その行の最後まで続きます。 そうでない場合、このファイルは フリーフォーマットかつトークン指向の文法で書かれた、 一連のサーバエントリか動作全体のオプションの記述で構成されます。

トークンには 4 種類あります: すなわち、文法キーワード、数字 (つまり10進数を並べたもの)、 クォートされていない文字列、クォートされた文字列です。 クォートされた文字列はダブルクォートで囲まれ、空白文字を含むことができます (クォートされた数値は文字列として扱われます)。 クォートされていない文字列は、空白で区切られる任意のトークンであり、 数値やクォートされた文字列でなく、 特殊文字 `,', `;', `:', `=' も含まないものです。

任意の数の空白文字はサーバエントリ中のトークンを区切りますが、 それ以外には無視されます。 標準の C 言語形式のエスケープ文字 (\n, \t, \b, 8進数, 16進数) を用いて 表示不可能な文字列や文字列の区切り文字を文字列中に埋め込むことができます。

各サーバエントリは、キーワード `poll' または `skip'、 これに続くサーバ名、その後に続くサーバオプション、 さらにその後に続く任意の数のユーザ記述から構成されます。 注意: 一番起こしやすい文法エラーの原因は、 ユーザオプションとサーバオプションを混ぜてしまうことです。

後方互換性のため、キーワード `server' は `poll' と同義になります。

英語に似せるため、ノイズワード `and', `with', `has', `wants', `options' を エントリ中の任意の場所で使うことができます。 これらは無視されますが、エントリがずっと読みやすくなります。 区切り文字 ':', ';', ',' も同じく無視されます。

poll 対 skip¶

`poll' を指定すると、fetchmail が引き数なしで実行した時、 このホストへの問い合わせが行われます。 `skip' を指定すると、コマンドラインで明示的に指定しない限り fetchmail はこのホストにポーリングを行いません。 (`skip' を使うと、テスト用エントリで安全に実験を行なうことや、 一時的に落ちているホスト用のエントリを簡単に無効にすることができます。)

キーワード/オプションのまとめ¶

以下は正式なオプションです。 大括弧 ([]) で括られているキーワードサフィックスは省略可能です。 コマンドラインオプションに対応するものの後には、 `-' と適切なオプション文字があります。

正式な動作全体のオプションを以下に示します:

以下の正式なサーバオプションを示します:

正式なユーザオプションを以下に示します:

ユーザオプションは全てサーバオプションより後でなければいけません。

.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) に 送られるようになります。

ヘッダ対 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 リストに対してのみマッチングを行わせることができます。