Provided by: manpages-ja_0.5.0.0.20071115-1_all bug

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'
       を使うと、テスト用エントリで安全に実験を行なうことや、
       一時的に落ちているホスト用のエントリを簡単に無効にすることがでい泙后)

  /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                             が無視する文字列値
                                    (拡張スクリプトで使うことがでい泙)。

       ユーザオプションは全てサーバオプションより_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         に渡されます
       (ローカル名マッピングは適用_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 アドレスとして_fetchmail          のクライアント側から
       メーリングリストを管理することがでい泙后    あなたのユーザ名が   `esr'
       であり、自分宛のメールを受け取ることと   (例えば)   "fetchmail-friends"
       という             名前のメーリングリストの管理を両方やりたいとします。
       それから、あなたのクライアントマシンで
       エイリアスのリストも管理したいものとします。

       サーバでは、`fetchmail-friends'           を          `esr'          に
       エイリアス設定することがでい泙后 それから、.fetchmailrc では  `to  esr
       fetchmail-friends    here'を宣言します。    すると、`fetchmail-friends'
       をローカルアドレスとして含んでいる              メールが取得されたとぁ
       メーリングリストの名前が                                           SMTP
       リスナが見ている受信者のリストに追加されます。
       したがって、エイリアスの展開はローカルで行われます。   必ず、`esr'   を
       fetchmail-friends          のローカルのエイリアス展開に含めてください。
       さもないと、このメーリングリストだけが宛先になっている
       メールを絶対に見ることがでい泙擦鵝
       また、リスナの「自分にも」というオプションを必ずセットして    (sendmail
       では       -oXm       コマンドラインオプションか、OXm       宣言です)、
       あなたが送ったメッセージのエイリアス展開から
       あなたの名前が削除されないようにしてください。

       しかし、このトリックに問題がないわけではありません。
       あなたがローカル名として宣言して
       _fetchmail
       を実行しているローカルユーザに送られますが、
       それが本当に正しい処置なのかをプログラム側から知る方法はありません。

  方
       マルチドロップメールボックスと、デーモンモードで複数のユーザにサービスを行う
       fetchmail                                  を同時に使ってはいけません。
       繰り返しますが、メーリングリストからのメールで問題が起こります。
       このようなメールには通常、受信者個人のアドレスが書かれていないのです。
       fetchmail   が  envelope  アドレスを推定でい覆韻譴弌△海里茲Δ淵瓠璽襪
       fetchmail を実行したユーザ (root  であることが多いでしょう)  にしか届-
       ません。        また、ブラインドコピーの宛先になっているユーザはい辰函
       このようなメールが全く読めないでしょう。

       もし、 fetchmail を使って 1 つのメールドロップから POP や  IMAP  経由で
       複数ユーザ宛のメールを取得しようと考えているならば、考え直してください
       (そして、前述のヘッダと            envelope            アドレスに関する
       セクションを読み直してください)。          メールは単にメールサーバの-
       ューに入れておぁ fetchmail の ETRN や ODMR モードを使って定期的に SMTP
       での送信を行わせる方が犬い笋蠅たでしょう
       (この場合はもちろん、メールサーバでのメールの邑期限よりも短い間隔で
       ポーリングをしなければならないことになります)。    このような設定がで-
       ないのならば、UUCP による配送を設定してみてください。

       どうしてもこの目的でマルチドロップを_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                        が複数のホストに問い合わせを行う場合、
       _~/.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)