     [file gnus-overrides-ja.texi not included]

Message
*******

This file documents Message, the Emacs message composition mode.

このファイルは Emacs のメッセージ作成モードである Message に関する説明文書です。

Copyright © 1996-2012 Free Software Foundation, Inc.

     Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.3 or any later version published by the Free Software Foundation; with no Invariant Sections, with the Front-Cover texts being ``A GNU Manual'', and with the Back-Cover Texts as in (a) below.  A copy of the license is included in the section entitled ``GNU Free Documentation License''.

     この文書を、フリーソフトウェア財団発行の GNU フリー文書利用許諾契約書第 1.3 版またはそれ以降の版が定める条件の下で複製、配布、あるいは変更することを許可します。変更不可部分は指定しません。“A GNU Manual”は表表紙テキスト、以下の (a) は裏表紙テキストです。この利用許諾契約書の複写は「GNU フリー文書利用許諾契約書」という章に含まれています。

     (a) The FSF's Back-Cover Text is: ``You have the freedom to copy and modify this GNU manual.  Buying copies from the FSF supports it in developing GNU and promoting software freedom.''

     (a) FSF の裏表紙テキスト:「あなたにはこの GNU Manual を複製したり変更する自由があります。FSF からの複写の購入は GNU の開発とソフトウェアの自由の促進を支援します。」

Gnus のすべてのメッセージの作成 (メールとニュースの両方) は、メッセージモードのバッファーで行ないます。

Message は Gnus とともに配布されます。このマニュアルに対応する Gnus の版は Ma Gnus v0.2 です。

インターフェース
********

プログラム (または人) がメッセージに反応したいとき---返答、フォローアップ、転送、取り消しをしたいとき---そのプログラム (または人) はちょうどそのメッセージがあるバッファーにポイントを置いて、必要な命令を呼び出すはずです。すると Message は、適切なヘッダーで満たした新しい message モードのバッファーを出現させてくれるので、利用者はメッセージを送る前にそれを編集することができます。

Message モードのツールバーをカスタマイズすることができます。M-x customize-apropos RET message-tool-bar を試してみてください。この機能を利用できるのは Emacs だけですが。

新しいメールメッセージ
===========

message-mail 命令は、新しいメッセージバッファーを出現させます。

二つの省略可能な引数が受け付けられます: 最初のものは To ヘッダーとして、二番目は Subject ヘッダーとして使われます。もしこれらが nil だったら、それらの二つのヘッダーは空になります。

新しいニュースメッセージ
============

message-news 命令は、新しいメッセージバッファーを出現させます。

この関数は二つの省略可能な引数を受け付けます。最初のものは Newsgroups ヘッダーとして、二つ目のものは Subject ヘッダーとして使われます。もしこれらが nil だったら、それらの二つのヘッダーは空になります。

返答
==

message-reply 関数は、現在のバッファーにあるメッセージへの返答のメッセージバッファーを出現させます。

Message は返答がどこに行くか (see Responses) を標準の方法で決定しますが、message-reply-to-function 変数をいじくることによって、あなたの必要に応じてその振る舞いを変えることができます。

From の代わりに Sender に返答を送りたいのであれば、このようなことができます:

     (setq message-reply-to-function
           (lambda ()
            (cond ((equal (mail-fetch-field "from") "somebody")
                    (list (cons 'To (mail-fetch-field "sender"))))
                  (t
                   nil))))

この関数は、返答しようとする記事がヘッダー部分に狭められたバッファーで呼ばれます。

ご覧のように、この関数はリストを返さなければなりません。この場合、To ヘッダーがそうなるべきだと判断すれば ((To . "Whom")) を返します。そうでなければ単に nil を返すだけで、To ヘッダーを決定する標準の方法が使われるでしょう。

リストのそれぞれの要素は cons セルです。CAR はヘッダーの名前 (例えば Cc) で、CDR はヘッダーの値 (例えば larsi@ifi.uio.no) です。これらすべてのヘッダーは、送出されるメールのヘッダーに挿入されます。

広い返答
====

message-wide-reply は、現在のバッファーにあるメッセージへの広い返答のメッセージバッファーを出現させます。「広い返答」とは To、 From (または Reply-to) および Cc ヘッダーに挙げられているすべての人たちに届く返答です。

Message は返答がどこに行くかを決定するために標準の方法を使いますが、 message-wide-reply-to-function をいじくることによって、振る舞いをあなたの必要に合うように変更することができます。それは message-reply-to-function と同じやり方で使われます (see Reply)。

正規表現 (または正規表現のリスト) message-dont-reply-to-names に合致するアドレスは Cc ヘッダーから取り除かれます。nil にすると、あなたの名前だけが取り除かれます。

message-prune-recipient-rules は、広い返答をするときに特定のアドレスを取り除くために使います。重複したアドレスのようなものを削除するために使うという意味です。これはリストのリストです。最初の要素は、ある規則を適用するための、特定のアドレスに合致する正規表現です。そして 2つ目は、取り除くべきアドレスに合致するための、最初の正規表現に基づいて拡張される正規表現です。

と、説明はややこしいのですが、使うのは簡単です。

例えば foo@example.org からメールを受け取ったのだけれど、 Cc のリストに実は同じ人の foo@zot.example.org が含まれていると、広い返答はそれら両方のアドレス宛てに出て行ってしまうでしょう。

これを避けるには、以下のようなことをすれば良いのです:

     (setq message-prune-recipient-rules
           '(("^\\([^@]+\\)@\\(.*\\)" "\\1@.*[.]\\2")))

例えばもし、cvs@example.org からのメッセージに対するすべての広い返答がそのアドレスだけに行き、他には行かないようにしたい (つまり受取人のリストに cvs@example.org があったら、他のすべての受取人を宛先から除外したい) のであれば:

     (setq message-prune-recipient-rules
           '(("cvs@example.org" ".")))

message-wide-reply-confirm-recipients が非-nil だったら、複数の受取人に返答したいかどうかの確認を求められます。ディフォルトは nil です。

フォローアップ
=======

message-followup 命令は、現在のバッファーにあるメッセージにフォローアップするためのメッセージバッファーを出現させます。

Message はフォローアップがどこに行くかを標準の方法を使って決定しますが、 message-followup-to-function をいじくることによって、あなたの必要に合うように振る舞いを変更することができます。それは message-reply-to-function と同じやり方で使われます (see Reply)。

message-use-followup-to 変数は Followup-To ヘッダーに関して何をするか (訳注: To ヘッダーをどうやって決定するか) を指定します。それが use だったら、いつもその値を使います。もし ask だったら (これがディフォルトです)、その値を使うかどうかを尋ねます。もし t だったら、その値が (文字通り) poster でない限り、その値を使います (訳注: message-use-followup-to の値が t で、 Followup-To ヘッダーの値が poster だったら、それを使うかどうかを尋ねます。なお、実際に To ヘッダーに使われるのは、 Mail-Reply-To、Reply-To および From ヘッダーの中で、最初に見つかったメールアドレスです)。nil であれば、値を使いません。

ニュースを取り消す
=========

message-cancel-news 命令は、現在のバッファーにある記事を取り消します。

message-cancel-message の値が取り消し記事の本文に挿入されます。ディフォルトは I am canceling my own article. です。

Message がニュース記事をポストするとき、ディフォルトで Cancel-Lock ヘッダーを挿入します。これはあなた自身が書いたメーッセージをあなただけが取り消すことができることを保証する暗号化されたヘッダーで、すぐれものです。欠点は、.emacs ファイル (Gnus が秘密の cancel lock パスワード (最初にこの機能を使うときに自動的に生成されます) を格納する場所) をなくしてしまうと、メッセージの取り消しができなくなってしまうことです。自分でパスワードを管理したいならば、以下のようなものを ~/.gnus.el ファイルに入れてください:

     (setq canlock-password "geheimnis"
           canlock-password-for-verify canlock-password)

そのヘッダーを挿入するかどうかは、message-insert-canlock 変数によって制御されます。

まだ多くのニュースサーバーが Cancel-Lock ヘッダーを重要視していませんが、将来は変わることが期待されます。

ニュース記事の置き換え
===========

message-supersede 命令は、現在のバッファーにあるメッセージを置き換えるためのメッセージバッファーを出現させます。

message-ignored-supersedes-headers に合致するヘッダーは新しいメッセージバッファーを出現させる前に取り除かれます。ディフォルトは

^Path:\\|^Date\\|^NNTP-Posting-Host:\\|^Xref:\\|^Lines:\\|

^Received:\\|^X-From-Line:\\|^X-Trace:\\|^X-Complaints-To:\\|

Return-Path:\\|^Supersedes:\\|^NNTP-Posting-Date:\\|^X-Trace:\\|

^X-Complaints-To:\\|^Cancel-Lock:\\|^Cancel-Key:\\|^X-Hashcash:\\|

^X-Payment:\\|^Approved: です。

転送
==

message-forward 命令は、現在のバッファーにあるメッセージを転送するためのメッセージバッファーを出現させます。接頭引数が与えられると、ニュースを使って転送します。

message-forward-ignored-headers
     この正規表現に合致するすべてのヘッダーが、転送されるメッセージから削除されます。

message-make-forward-subject-function
     転送されるメッセージの、表題ヘッダーを作るために呼ばれる関数のリストです。前の関数で作られた表題は、続くそれぞれの関数に渡されます。

     提供されている関数は次の通りです:

     message-forward-subject-author-subject
          記事の出どころ (著者かニュースグループ) を、括弧 ([...]) で囲んで表題の前に付けます。

     message-forward-subject-fwd
          記事の表題の前に Fwd: を置きます。

message-wash-forwarded-subjects
     この変数が t だったら、以前に転送されたことを示す痕跡 (Fwd:, Re:, (fwd) のようなもの) を、新しい表題を組み立てる前にはぎ取ります。ディフォルト値は nil です。

message-forward-as-mime
     この変数が t (ディフォルト) だったら、転送されるメッセージは MIME RFC822 パートとして埋め込まれます。nil だった場合は、以前に MIME に対応していなかった Gnus がしたように、転送されるメッセージのコピーが、ただ単に新しいメッセージに埋め込まれます。

message-forward-before-signature
     非-nil だったら署名の前に、それ以外だったら後に、転送するメッセージを置きます。

再送
==

message-resend 命令は、利用者にアドレスを入力することを要求して、現在のバッファーにあるメッセージをそのアドレスに再送します。

正規表現 message-ignored-resent-headers に合致するヘッダーは、メッセージを送る前に取り除かれます。

弾かれたメールメッセージ
============

message-bounce 命令は、もし現在のバッファーに弾かれたメールメッセージがあったら、弾かれたことの情報を取り除いたメッセージバッファーを出現させます。「弾かれたメッセージ」とは、一般には mailer-daemon から配送不可として突き返されたメールです。

正規表現 message-ignored-bounced-headers に合致するヘッダーは、バッファーを出現させる前に取り除かれます。ディフォルトは ^\\(Received\\|Return-Path\\|Delivered-To\\): です。

メーリングリスト
========

メーリングリストに投稿する際に、その投稿に対するフォローアップ記事を指定した場所に直接送ってもらいたいことがあります。Mail-Followup-To (MFT) はまさにこれを可能にするために作られました。これが役に立つ場合の例を三つ:

  * メーリングリストに投稿する人は、投稿した人ではなく、メーリングリストだけに返答を送るべきであることを、MFT を使って表現することができます。これは、投稿者がすでにそのメーリングリストを購読している場合が該当します。

  * メーリングリストに投稿する人は、メーリングリストだけでなく投稿した人にも返答を送るべきであることを、MFT を使って表現することができます。これは、投稿者がそのメーリングリストを購読していない場合が該当します。

  * メッセージが複数のメーリングリストに投稿されている場合に、それ以降の議論を一つのメーリングリストだけで行なうことを指定するためにも MFT を使うことができます。議論がいくつかのメーリングリストで行なわれてしまうとばらばらになりやすいし、フォローするのが難しくなってしまいますから。

Gnus は他の人のメッセージにある MFT ヘッダーを尊重します (すなわち、だれか別の人の投稿にフォローアップするとき)。また、外に出て行くメッセージのための、道理にかなった MFT ヘッダーを作成することのサポートも提供します。

正しい MFT ヘッダーを自動的に作る
-------------------

投稿する記事の MFT ヘッダーを Gnus が自動的に作ってくれるようにするための第一歩は、購読しているメーリングリストのアドレスのリストを Gnus に与えることです。一つ以上の方法でこれを行なうことができます。以下の変数が手ごろでしょう。

message-subscribed-addresses
     これは購読しているメーリングリストのアドレスのリストでなければなりません。ディフォルト値は nil です。例:

          (setq message-subscribed-addresses
                '("ding@gnus.org" "bing@noose.org"))

message-subscribed-regexps
     これは購読しているメーリングリストのアドレスを示す正規表現のリストでなければなりません。ディフォルト値は nil です。上記と同じ結果を成し遂げたい場合の例:

          (setq message-subscribed-regexps
                '("\\(ding@gnus\\)\\|\\(bing@noose\\)\\.org")

message-subscribed-address-functions
     これは MFT ヘッダーの値を決めるために (一度に一回!!) 呼ばれる関数のリストです。それらの関数には引数が無いことを忠告しておきましょう。ディフォルト値は nil です。

     Gnus ではこの変数のために定義された、良い関数の候補があります。関数 gnus-find-subscribed-addresses は、subscribed グループパラメーター (see グループパラメーター (The Gnus Manual)) が非-nil に設定されているグループに対応するアドレスのリストを返します。こんなふうに使ってください。

          (setq message-subscribed-address-functions
                '(gnus-find-subscribed-addresses))

message-subscribed-address-file
     あなたはもしかしたら酔狂な人 (原典: one organized human freak) で、購読しているすべてのメーリングリストのアドレスのリストを別ファイルで持っているかもしれません! そうならば、単にこの変数をそのファイル名にすることによって、人生は善きものになるでしょう。

上記の複数の変数を使うことができます。それらの値はすべて「加えられ」ます。何らかの使える方法で。:-)

さあ用意ができました。いつものようにメッセージの作成を始めましょう。そしていつも通りに送信しましょう。メッセージが送出される直前に Gnus の MFT を作る仕掛けが動作して、メッセージがすでに MFT フィールドを持っているかどうかを調べます。もしそれがあるなら、それは放っておかれます (その場合にそれが空っぽだったら、そのフィールドが削除されて自動生成されたもので置き換えられることはありません。これは個々のメッセージについて MFT の生成を禁止させる基本です)。無かった場合は受取人のアドレスのリスト (To: と Cc: ヘッダーにある) を、それらの一つが購読しているメーリングリストのアドレスかどうかを調べます。それらのどれもがメーリングリストのアドレスでなかったら、MFT は作られません。それ以外の場合には MFT がヘッダーに付け加えられ、その値は To: と Cc: にあるすべてのアドレスに設定されます。

うーむ。そうするとあなたは「購読していないメーリングリストにメールを送信するときはどうなるの?  私は余分のコピーが欲しいことを MFT で言いたい」と尋ねますね (これは MFT が無い場合と同様に処理されるでしょう。しかし、 to-address で設定された他の誰かより優先させるために、明示的な MFT を使うことができます)。関数 message-generate-unsubscribed-mail-followup-to が役に立つかもしれません。これはディフォルトで C-c C-f C-a に割り当てられています。どんな場合でも、あなたは自分が選んだ MFT を挿入することができます; それを始めるのに C-c C-f C-m (message-goto-mail-followup-to) が助けてくれるでしょう。

MFT 投稿の尊重
---------

メーリングリストに投稿された記事にフォローアップするとき、その記事が MFT ヘッダーを持っていたら、Gnus の動作は変数 message-use-mail-followup-to の値によって決まります。この値は以下のどれかになります:

use
     常に MFT を尊重します。フォローアップ記事の To: と Cc: ヘッダーは、元の記事の MFT ヘッダーから引き出します。これがディフォルトです。

nil
     常に MFT を尊重しません (完璧に無視)。

ask
     どうするかを尋ねます。

MFT を尊重することは良いネチケット (netiquette) であると考えられています。どこにフォローアップする必要があるかを、メッセージを投稿した人はあなたよりよく知っているはずですから。

命令
**

バッファーに入る
========

何か他のメッセージに応答するときは、たいていメッセージバッファーで書き上げますよね。Message は多くの引用文を扱ったり、署名を削除したり、文章の整形をしたり、あるいはあなたが使っている設定に依存するいろんなことをします。 Message は普通はうまく動作しますが、ときどき間違えもします。それらの間違いを利用者が正すことができるように、Message はあるまとまった動作を自動的に行なう前にアンドゥ (やり直し) の境界を設定します。それによって、ほんの何回かアンドゥ・キー (通常 C-_) を押せば、未編集のメッセージに戻すことができます。

ヘッダー命令
======

ヘッダーに移動するための命令
--------------

以下の命令は対象になっているヘッダーに移動します。存在しなければ挿入されます。

C-c ?
     メッセージモードの説明を表示します。

C-c C-r C-t
     To ヘッダーに行きます (message-goto-to)。

C-c C-f C-o
     From ヘッダーに行きます (message-goto-from)。(キーバインド中の“o”は創作者 (Originator) に由来しています。)

C-c C-f C-b
     Bcc ヘッダーに行きます (message-goto-bcc)。

C-c C-f C-w
     Fcc ヘッダーに行きます (message-goto-fcc)。

C-c C-f C-c
     Cc ヘッダーに行きます (message-goto-cc)。

C-c C-f C-s
     Subject ヘッダーに行きます (message-goto-subject)。

C-c C-f C-r
     Reply-To ヘッダーに行きます (message-goto-reply-to)。

C-c C-f C-n
     Neswsgroups ヘッダーに行きます (message-goto-newsgroups)。

C-c C-f C-d
     Distribution ヘッダーに行きます (message-goto-distribution)。

C-c C-f C-f
     Followup-To ヘッダーに行きます (message-goto-followup-to)。

C-c C-f C-k
     Keywords ヘッダーに行きます (message-goto-keywords)。

C-c C-f C-u
     Summary ヘッダーに行きます (message-goto-summary)。

C-c C-f C-i
     high という値を持つ Importance: ヘッダーを挿入します。このヘッダーは受信者にそのメッセージの重要性を知らせるために使われるものです。もしバッファーにすでにこのヘッダーがある場合は、RFC 1376 に準じた三つの値 low、normal および high を循環させます。

C-c C-f C-a
     講読していないメーリングリストに投稿する場合に見合った Mail-Followup-To: ヘッダーを挿入します。講読していないメーリングリストに元記事を投稿するときは、Mail-Followup-To: ヘッダーに手で記入しなければなりません。内容は、普通はメーリングリストのアドレスとあなた自身のアドレスです。この関数はそのようなヘッダーを自動的に挿入します。これは現在のメールのバッファーから To: ヘッダーの内容を抜き出し、それに現在の user-mail-address を追加します。

     省略可能な引数 include-cc が nil ではない場合は、 Cc: ヘッダーにあるアドレスも Mail-Followup-To: ヘッダーに置かれます。

ヘッダーを変更するための命令
--------------

C-c C-o
     message-header-format-alist に従ってヘッダーを並べ替えます (message-sort-headers)。

C-c C-t
     フォローアップしようとするメッセージの Reply-To もしくは From ヘッダーを含む To ヘッダーを挿入します (message-insert-to)。

C-c C-n
     返答しようとする記事の Followup-To もしくは、Nesgroups ヘッダーを反映した Newsgroups ヘッダーを挿入します (message-insert-newsgroups)。

C-c C-l
     メーリングリスト宛てだけにメッセージを送ります。 To: と Cc: ヘッダーから、そのメーリングリスト以外のアドレスを削除します。

C-c M-n
     開封確認要求を挿入します。 (message-insert-disposition-notification-to)。もし受信者が RFC 2298 をサポートしていれば、彼女はそのメッセージを受け取ったことを知らせてくれるでしょう。

M-x message-insert-importance-high
     high という値を持つ Importance ヘッダーを (必要ならすでに存在するものを消去してから) 挿入します。

M-x message-insert-importance-low
     low という値を持つ Importance ヘッダーを (必要ならすでに存在するものを消去してから) 挿入します。

C-c C-f s
     現在の Subject ヘッダーを変更します。新しい Subject を尋ねて (was: <古い表題>) を追加します。そういう記事を受け取った人がさらに返信するときに、古い表題は削除することができます。 message-subject-trailing-was-query (Message Headers) を見てください。

C-c C-f x
     クロスポストのために、対象グループとともに FollowUp-To ヘッダーを設定し、その対象グループが Newsgroups ヘッダーに存在しなかったらそこに追加し、かつ本文に注意書きを入れます。 message-cross-post-default が nil になっているか、またはこの命令が接頭引付きで呼ばれると、Follow-Up ヘッダーが設定されるだけで、Newsgroups ヘッダーへの追加は行なわれません。注意書きを入れる関数は message-cross-post-note-function 変数で制御されます。

C-c C-f t
     To ヘッダーの内容を Cc か Bcc ヘッダーの内容で置き換えます。(Cc ヘッダーが無い場合に限って、代わりに Bcc ヘッダーが使われます。)

C-c C-f w
     初めはそのメッセージが広い返答のために作られたものでなかった場合でも、広い返答をしているように To と Cc ヘッダーを挿入します。

C-c C-f a
     X-No-Archive: Yes をヘッダーに挿入して、本文に注意書きを入れます。ヘッダーと注意書きは message-archive-header と message-archive-note を使ってカスタマイズすることができます。接頭引数付きで呼ばれると、挿入するテキストを要求します。本文に注意書きを入れたくない場合は、 message-archive-note を nil にしてください。

移動
==

C-c C-b
     メッセージの本文の先頭に移動します (message-goto-body)。

C-c C-i
     メッセージの署名に移動します (message-goto-signature)。

C-a
     ヘッダーの値の先頭にいるときは行の先頭に移動し、そうでないときはヘッダーの値の先頭に移動します。(ヘッダーの値というのは、ヘッダー名およびコロンの後にあるものです。) この動作は変数 message-beginning-of-line をトグル切り替えすることによって無効にすることができます。

挿入
==

C-c C-y
     返答しようとしているメッセージをメッセージバッファーに yank します (messsage-yank-original)。

C-c C-M-y
     バッファー名を尋ねて、そのバッファーの内容をメッセージバッファーに yank します (message-yank-buffer)。

C-c C-q
     Yank されたメッセージを折り返して耳を揃えます (message-fill-yanked-message)。警告: もし変なやり方で引用されていると、yank された文章をひどくぐちゃぐちゃにしてしまうかもしれません。もっとも、どんなものが安全かは、すぐにわかるでしょうけれど。とにかく、何が起きても C-x u (undo) が使えるのだから問題無いことだけは、覚えておいてください。

C-c C-w
     バッファーの最後に署名を挿入します (message-insert-signature)。

C-c M-h
     メッセージのヘッダーを挿入します (message-insert-headers)。

C-c M-m
     現在の記事のある領域を、それらを囲むためのタグで印を付けます。 message-mark-insert-begin と message-mark-insert-end を見てください。接頭引数を付けて使うと、slrn ふうの verbatim (文章を一言一句そのまま表す) 記号の対 (#v+ と #v-) を使います。(訳注: そういうメッセージを Gnus で表示すると、ディフォルトではその領域が一つのパートとして扱われ、また強調表示されます。)

C-c M-f
     現在の記事にファイルを挿入して、その領域を囲むためのタグで印を付けます。 message-mark-insert-begin と message-mark-insert-end を見てください。接頭引数を付けて使うと、slrn ふうの verbatim (文章を一言一句そのまま表す) 記号の対 (#v+ と #v-) を使います。(訳注: そういうメッセージを Gnus で表示すると、ディフォルトではその領域が一つのパートとして扱われ、また強調表示されます。)

MIME
====

Message は MIME に対応した送信用のエージェントです。ふつう利用者は、MIME にするために何かする必要はありません。Message は自動的に Content-Type および Content-Transfer-Encoding ヘッダーを付加します。

利用者が MIME でマルチパートを使いたい最も一般的なものは、送出するメールに「添付」を付け加えることでしょう。これは C-c C-a 命令 (M-x mml-attach-file) で行なうことができ、その際ファイル名と MIME タイプが尋ねられます。

あなたの Emacs がドラッグ＆ドロップをサポートしていれば、Message バッファーにファイルをドロップすることもできます。変数 mml-dnd-protocol-alist で、Message バッファーにファイルをドロップするときにどんなことを行なうかを指定します。変数 mml-dnd-attach-options は、ファイルをドロップするときにどの MIME オプションを指定したいかを制御します。それをリストにする場合、有効なオプションは type, description および disposition です。disposition は暗に type を含みます。nil だったらオプションを尋ねません。t にすると、オプションを指定するかどうかを尋ねます。

さらに MML 言語 (see MIME メッセージの作成 (The Emacs MIME Manual)) を使えば、どんな複雑なマルチパートでも自由に作ることができます。

国際化ドメイン名
========

IDNA は非-ASCII ドメイン名を可読な ASCII 文字列にエンコードするための標準の手段です。詳細は RFC 3490 で見つかります。

Message は IDNA に準拠した送信エージェントです。利用者は IDNA のために一般には何もする必要がありません。 Message は From、To および Cc ヘッダーにある非-ASCII ドメイン名を自動的にエンコードします。

もっと IDNA が有名になるまでは、Message は実際にドメイン名を IDNA エンコードすべきかどうかの確認を求めることになっています。今のところは、利用者の幾人かはドメイン名に非-ASCII 文字を含むことができることに気づいていないかもしれないので、彼らが偶然に非-ASCII ドメイン名をタイプしてしまったときのために安全ネットを張っているわけです。

変数 message-use-idna は IDNA を使うかどうかを制御します。この変数が nil だったら IDNA エンコードは行なわれません。シンボル ask に設定されていると利用者は確認を求められます。また、t に設定されていると (IDNA が完全に利用可能ならば、それがディフォルトです)、自動的に IDNA エンコードが行なわれます。

実験的に IDNA エンコードを行ないたいならば、(エンコードされた非-ASCII ドメイン名を得るために) メッセージの編集中に M-x message-idna-to-ascii-rhs RET をタイプしてください。

この機能を使うには GNU Libidn (http://www.gnu.org/software/libidn/) をインストールしておかなければなりません。

セキュリティー
=======

MML 言語を使うことによって、Message は電子署名された、または電子暗号化されたメッセージを作ることができます。Message (と言うか MML) は、現在 PGP (RFC 1991), PGP/MIME (RFC 2015/3156) および S/MIME をサポートしています。

署名と暗号化のコマンド
-----------

MIME パートに対してセキュリティーの操作を行なうための MML への指示は、以下のように署名の場合は C-c C-m s キーマップを使って、暗号化の場合は C-c C-m c キーマップを使って行ないます。

C-c C-m s s

     S/MIME を使って現在のメッセージに電子署名します。

C-c C-m s o

     PGP を使って現在のメッセージに電子署名します。

C-c C-m s p

     PGP/MIME を使って現在のメッセージに電子署名します。

C-c C-m c s

     S/MIME を使って現在のメッセージを電子暗号化します。

C-c C-m c o

     PGP を使って現在のメッセージを電子暗号化します。

C-c C-m c p

     PGP/MIME を使って現在のメッセージを電子暗号化します。

C-c C-m C-n
     メッセージからセキュリティー関連の MML タグを削除します。

これらの命令は、その場でメッセージに署名したり暗号化するわけではなく、単にセキュリティーのための適切な MML タグを挿入して、メッセージが実際に送信されるときにその動作を実行するように、MML エンジンに指示を与えるだけです。それらは他の仕事、例えば暗号化されたメールを送りたい相手の人の S/MIME の証明書を探して、取り寄せるようなことも行なうかもしれません。mml 解析エンジンが MML で書かれたメッセージを適切に MIME メッセージに変換するとき、セキュリティーのためのタグは、パートまたはマルチパートのどちらかのタグで置き換えられます。メッセージが他の mml パートも含んでいる場合にはマルチパートのタグが使われ、他のパートが無い場合は単一のパートのタグが使われるでしょう。このようにして、署名される/暗号化されるマルチパートのメッセージに対し、メッセージ・モードは「正しいこと (登録商標)」(原文: the Right Thing (TM)) を行ないます。

署名そして特に暗号化はしばしば機密情報を送信するときに使われるので、メールが本当に署名または暗号化されることを確かめるための何らかの手段を必要とするでしょう。上記の署名/暗号化のための命令を実行した後でなら、 C-u C-c RET P (mml-preview) を使うことによって生の記事を下見することが可能です。そうして、あなたの以前に大切だった人に関する、あるいは、この前の夜の変なパーティーで、あのおかしな身なりの人が実際にやったことに関するあなたの長い罵倒が、本当に暗号化されて送信されるであろうことを確認することができます。

注意!  PGP/MIME と S/MIME のどちらも RFC822 ヘッダーを署名/暗号化しません。それらは MIME パートにのみ作用します。機密の表題とともにメールを送ってしまう前に、このことを肝に命じておいてください。

メッセージを暗号化するとき、Gnus はディフォルトで「署名+暗号化」(メッセージに対して署名と暗号化の両方が行なわれる) モードを使います。特定のメッセージに対してこれを行なわせたくないならば、 mml-secure-message-encrypt-* 命令に接頭引数を与えて (例えば C-u C-c C-m c p を使って) ください。

上記のセキュリティー命令を実際に使うのはさほど難しくありません。少なくとも、すべての関係するプログラムが適切に通信し合うことを確かめることと比較して。そこで、外部のどんなライブラリーまたはプログラムが必要かについて、およびいくつかの些細で一般的なヒントを述べることにします。

S/MIME を使う
----------

注意!  この章は近代的な暗号法、S/MIME、さまざまな PKCS の標準、OpenSSL などの基礎に、あなたが精通していることを想定しています。

Message (それに MML) が S/MIME をサポートするには OpenSSL が必要です。OpenSSL は実際の S/MIME による署名/暗号化の処理を実行します。OpenSSL は http://www.openssl.org/ で見つかるでしょう。OpenSSL 0.9.6 以降のものが動作するはずです。バージョン 0.9.5a は証明書からメールアドレスを抽出することができません。またそれは MIME のセパレータに余計な CR 文字を挿入するので、変なメールを送る人だと思われたくなければ、それを使うことを避けたいでしょう。(もっともあなたは S/MIME のメッセージを送った時点で、おそらくその変人コンテストでの勝利を逃してしまいましたが。)

暗号化されたメールを送るために個人の証明書は要りません。もっとも Message (MML) は、通信したい相手の人の証明書を必要としますけれど。これは C-c C-m c s をタイプしたときに尋ねられます。今のところ、証明書をローカルファイルから取り出すか DNS から取り寄せるかの、二つの方法があります。ローカルファイルを選択した場合、それは PEM 形式による X.509 証明書を含んでいる必要があります。DNS を選んだ場合には、その証明書が格納されているドメイン名を尋ねられます (ディフォルトは上手に推測したものです)。私が信じる限り Message (MML) は S/MIME の証明書を DNS から取り寄せる世界初のメール・エージェントなので、あまりたくさんの証明書がそこで見つかることは無いでしょう。少なくとも一つだけは simon.josefsson.org ドメイン (訳注: 原著者のサイト) に格納されたものがあるはずですが。LDAP は証明書を配給するためのもっと普及している手法で、それをサポートすることが計画されています。(話は変わりますが、 ldapsearch をコマンドラインから実行して証明書をファイルに取り込み、それを使うことができますよ。)

メッセージの署名については、ある種の設定無しでは OpenSSL は署名の処理を実行することができません。とりわけ、あなたの秘密鍵 (private key) と証明書がどこに格納されているかを教えてあげる必要があります。MML はその名にふさわしい smime.el という OpenSSL への Emacs インターフェースを使いますが、それはこの設定に使うためのための custom グループを持っています。ですから M-x customize-group RET smime RET を試して、眺めてみてください。

現在は、CA (または RA) と通信してあなた自身の証明書を生成することはサポートされていません。それに計画もありません。私は Netscape を使って、ネット上にある大きな CA の一つから無料の S/MIME の証明書をもらいました。Netscape は秘密鍵と証明書を PKCS #12 形式で輸出 (export) することができます。OpenSSL を使って、これを以下のように PEM 形式による素 (plain) の X.509 証明書に変換してください。

     $ openssl pkcs12 -in ns.p12 -clcerts -nodes > key+cert.pem

smime-keys 変数が key+cert.pem ファイルを指し示すようにしなければなりません。今や、あなたは署名されたメッセージを送信できるはずです。

注意!  あなたの鍵は今、暗号化されずにファイルに格納されたので、それの扱いには気を付けてください。暗号化された鍵をファイルに格納する機能はサポートされています。その場合は OpenSSL を呼び出す前に Gnus がパスフレーズを尋ねるでしょう。どうやってそれを成し遂げるかについては OpenSSL のドキュメントを読んでください。暗号化されていない鍵を使う (例えばそれらが安全なストレージにある、またはあなたが安全なシングル・利用者のマシンにいる) のであれば、パスフレーズの入力を要求されたとき、単に RET を押してください。

PGP/MIME を使う
------------

PGP/MIME は GNU Privacy Guard (http://www.gnupg.org/) のような、外部の OpenPGP の実装を必要とします。OpenPGP より以前の実装である PGP 2.x と PGP 5.x もサポートします。PGP の実装への一つの Emacs インターフェースである (see PGG (PGG Manual)) が含まれていますが、Mailcrypt もサポートします。See PGP Compatibility.

Message はデータを暗号化するために内部的に GnuPG (gpg コマンド) を呼びます。また、ある場合 (例えば暗号の解読や署名を行なう場合) には、 gpg はユーザーのパスフレーズを要求します。現在 gpg にパスフレーズを渡す方法として推奨されているのは、 gpg-agent プログラムを使うことです。

Emacs で gpg-agent を使うには、Emacs を起動する前にシェルで以下のコマンドを走らせる必要があります。

     eval `gpg-agent --daemon`

これは gpg-agent を実行するとともに gpg が gpg-agent と通信できるように、環境変数 GPG_AGENT_INFO を設定します。これを .xsession または .bash_profile に書き込むのは良い考えでしょう。See Invoking GPG-AGENT (Using the GNU Privacy Guard).

いったん gpg-agent が立ち上がると、それは gpg のために必要に応じてパスフレーズを尋ねます。X ウィンドウ・システムでは、パスフレーズを入力するための対話手段が新たに出現します。その対話手段は PIN Entry (pinentry コマンド) によって提供されますが、バージョン 0.7.2 のものは単一の tty 上の Emacs とは協調して動作することができません。したがって、もし文字コンソールを使っているのであれば、パスフレーズを gpg-agent のキャッシュに前もって入れておかなければならないでしょう。以下のコマンドを、そのために使うことができます。

     gpg --use-agent --sign < /dev/null > /dev/null

Lisp 変数 pgg-gpg-use-agent で gpg-agent を使うかどうかを制御します。See パスフレーズをキャッシュする (The PGG Manual), も参照してください。

古い実装との互換性
---------

注: もし gpg.el を使うのであれば、gpg-temp-directory で指定されるディレクトリーのパーミッションが必ず 0700 になっているようにしてください。

あなたの PGP の実装のドキュメントで詳しく述べられているので、あなた自身のための鍵の生成のしかたは、それに譲ります。

もしあなたが古い PGP 2.x の鍵を GnuPG に輸入してあって、PGP 2.x を使っている仲間に署名されかつ暗号化されたメッセージを送りたいとすると、受信者はあなたが送信したものを理解できないことを発見することになるでしょう。一つの解は、代わりに PGP 2.x を使うこと (すなわち、もし pgg を使っているのであれば、pgg-default-scheme を pgp に設定すること) です。さらに PGP 2.x を使っている仲間に、GnuPG に乗り換えることを説得しても良いでしょう。最後の代替手段として、署名と暗号化の動作を二段階 (分離署名してからメッセージを暗号化する) にすることができます。この振る舞いを変更したいのであれば、 mml-signencrypt-style-alist 変数をカスタマイズすることができます。例えば:

     (setq mml-signencrypt-style-alist '(("smime" separate)
                                         ("pgp" separate)
                                         ("pgpauto" separate)
                                         ("pgpmime" separate)))

これは署名と暗号化を二段階で行なわせることによって、PGP version 2 が理解できるメッセージを生成します。

(その問題に関するさらなる情報については、 http://www.gnupg.org/gph/en/pgp2x.html を参照してください。)

いろいろな命令
=======

C-c C-r
     現在のメッセージをカエサル変換 (別名 rot13) します (message-caesar-buffer-body)。ある範囲にバッファーが狭められていた場合は、バッファーの見える部分だけを変換します。数値接頭引数は文中のアルファベットを何文字分回転させるかを指定します。ディフォルトは 13 です。

C-c C-e
     ポイントとマークの間の文を省略します (message-elide-region)。文章は kill されて、変数 message-elide-ellipsis の値で置き換えられます。ディフォルトの省略符号として使われる値は ([...]) です。

     これは書法仕様変数なので、削除された行数を、または削除された文字数を表示させるために、それぞれ %l と %c を使うことができます。

C-c M-k
     現在位置のアドレスを削除します (訳注: この命令は作者や出どころが不明で、さらに悪いことに不完全な命令に見えます。必ず消したいアドレスの先頭にポイントを置いて使ってください。)

C-c C-z
     現在位置から署名まで、またはそれが無ければ記事の最後までの文を kill します (message-kill-to-signature)。

C-c C-v
     メッセージの本文において、領域が設定された場所以外のすべての文を消去します (message-delete-not-region)。

M-RET
     四本の空行を挿入します。そして、もしポイントが引用文の中間にあったのならば、引用文を整形し直します。

     例です:

          > これは何かの引用文です。 そして、ここにはもっと引用文があります。

     ポイントが「そして」の前にあるときに M-RET を押すと、以下のようになります:

          > これは何かの引用文です。

          *

          > そして、ここにはもっと引用文があります。

     * はポイントが置かれる場所です。

C-c M-r
     バッファーの名前を変更します (message-rename-buffer)。接頭引数が与えられると、新しいバッファー名の入力を要求します。

TAB
     message-tab-body-function が nil でなかったら、それが指定する関数を実行します。さもなければ、 text-mode-map か global-map の TAB キーに割り当てられている命令を使います。

送信
==

C-c C-c
     メッセージを送信し、現在のバッファーを bury-buffer します (message-send-and-exit)。

          訳注: bury-buffer は指定したバッファーを現在の Emacs 上に存在するバッファーのリストの最後の要素にする関数で、一般に重要度が低くなったバッファーに対して実行されます。それを見たい場合は C-x C-b を使ってください。ただしバッファーの名前が *sent ... * に変わっているはずです。

C-c C-s
     メッセージを送信します (message-send)。

C-c C-d
     メッセージバッファーを bury-buffer して (送信せずに) 終了します (message-dont-send)。

C-c C-k
     メッセージバッファーを kill して (送信せずに) 終了します (message-kill-buffer)。

メールの別名
======

message-mail-alias-type という変数で、どのような型のメールの別名 (mail alias) の伸張を使うかを制御します。今のところ二つの様式、 mailabbrev と ecomplete を使うことができます。もしこの変数が nil になっていると、メールの別名の伸張は行なわれません。

Mailabbrev は /etc/mailrc と ~/.mailrc ファイルを解析することによって動作します。それらのファイルは次のようになっています:

     alias lmi "Lars Magne Ingebrigtsen <larsi@ifi.uio.no>"
     alias ding "ding@ifi.uio.no (ding mailing list)"

このような行を ~/.mailrc ファイルに追加しておけば、 To や Cc (など) のヘッダーで lmi と書いて SPC を押すだけで、その別名を伸張してくれるはずです。

メッセージを送るときには伸張は行なわれません---すべての伸張は明示的に (訳注: 実際に自分でメールを書いているときに) 行なわれなくてはなりません。

ecomplete を使っていると、To と Cc ヘッダーにあるすべてのアドレスが、自動的に ~/.ecompleterc ファイルに格納されます。 To と Cc ヘッダーにテキストを書き込んだときに、 ecomplete はそこに格納されている値を調べて、どんな補完候補があるかを「エレクトリック」に (訳注: 巧妙なやり方で) 教えてくれるでしょう。それらの補完候補の一つを探すには、M-n コマンドでリストを下に読み進んでください。リストを昇るのは M-p、そして選択するのは RET です。

Emacs にスペルチェックさせる
=================

メッセージを Emacs でスペルチェックするために普及している二つの方法として ispell と flyspell があります。ispell の方は昔からあって、たぶんより一般的なパッケージです。あなたは最初にメッセージを書いてから、例によって全体を ispell に通し、すべての書き損じを修正するでしょう。メッセージを送信するときにそれを自動的に行なうためには、 .emacs ファイルに以下のようなものを入れてください。

     (add-hook 'message-send-hook 'ispell-message)

あなたが別の言語で書く習慣を持っているのならば、変数 ispell-message-dictionary-alist で切り替えることができます。 (訳注: 以下の連想リストの各要素で、ヘッダーのどれかに合致する正規表現と辞書を指定します。ただし japanese という辞書はありません (たぶん)。)

     (setq ispell-message-dictionary-alist
           '(("^Newsgroups:.*\\bde\\." . "deutsch8")
             (".*" . "default")))

ispell はインストールされている ispell プログラムに依存します。

人気があるもう一つの方法は flyspell を使うことです。このパッケージはあなたが書いている最中にスペルチェックを行ない、いろんな方法で間違ったスペルの語を指摘してくれます。

flyspell を使うには、以下のようなものを .emacs ファイルに入れてください。

     (defun my-message-setup-routine ()
       (flyspell-mode 1))
     (add-hook 'message-setup-hook 'my-message-setup-routine)

flyspell はインストールされている ispell プログラムに依存します。

変数
**

メッセージヘッダー
=========

Message はメッセージを作成する分野の第一線にあって、極めて意欲的です。その使命はニュースとメールのエージェントを統合することです。メールとニュースを一緒に送ることを可能にするためには、メッセージをメールで送ったものとニュースで送ったものがよく似た見栄えになるように、Message はすべてのヘッダーをそれ自身で作成しなければなりません。

message-generate-headers-first
     t だったら、すべての必要なヘッダーをメッセージを書き始める前に作成します。これは作成するヘッダーのリストであっても構いません:

          (setq message-generate-headers-first
                '(References))

     変数 message-required-headers、 message-required-mail-headers および message-required-news-headers は、どのヘッダーが必要かを指定します。

     変数 message-deletable-headers (後述) の設定によっては、いくつかのヘッダーが送信する前に消されて作り直されることに注意してください。

message-draft-headers
     Message が Gnus 上で走っている場合、メッセージバッファーはドラフトグループと関連付けられています。message-draft-headers は、そのドラフトグループにドラフトが記録されるときに、どのヘッダーが作成されるべきかを指示します。

message-from-style
     From ヘッダーをどういう見栄えにするかを指定します。以下の四つの値が使えます:

     nil
          アドレスだけです---king@grassland.com.

     parens
          king@granssland.com (Elvis Parsley).

     angles
          Elvis Parsley <king@grassland.com>.

     default
          引用符で囲む必要がある場合 (*) は parens と同様の見栄えにします。そうでなければ angles の場合と同じような見栄えにします。 parens の形式を使ってもなお引用符で囲まなければならない場合 (*) は、有無を言わずに angles の形式を使います。

          訳注*: フルネームの部分が特殊文字を含んでいる場合

message-deletable-headers
     前もって Message が作成したヘッダーのうち、このリストに含まれているものは投稿する前に削除されます。記事を投稿したとしましょう。それから、いたずら好きなあなたはそれをどこか別のグループに再び投稿することを決心したので、 *post-buf* バッファーに戻って Newsgroups 行を編集し、再び送り出したとします。ディフォルトでは、この変数は前に作られた古い Message-ID を取り除いて、新しいものを作ることを確実にします。もしこれが行なわれないと、おそらく帝国全体が滅亡して無政府状態がはびこり、猫が二本の足で歩き始めて世界を支配するでしょう。伝え聞くところによれば。

message-default-headers
     送信するメッセージに挿入されるヘッダー行です。編集前に挿入されるので、書き換えたり削除できます。もし文字列に設定されていれば、そのまま挿入されます。もし関数に設定されていると、呼ばれてその結果が挿入されます。

message-subject-re-regexp
     メッセージへの応答には Re:  で始まる表題があります。これは英単語の“response”の略では ありません。ラテン語で「それに応答して」 (in response to) と言う意味です。無教養な馬鹿者どもはこの事実をとり損ねて、代わりに忌まわしい Aw:  (antwort) や Sv:  (svar) を使うように、彼らのソフトウェアを「国際化」しました。それは無意味だし邪悪です。しかし、あなたはこれらの邪悪な道具を使う利用者と応対しなければならないかもしれません。そういう場合には、この変数をそれらの接頭語に合致する正規表現に設定することができます。私ですか?  私は規格に従わないメールはただ捨て去っているだけです。

     これは、返事をするときにそれらのヘッダーに対処するための値の例です:

          (setq message-subject-re-regexp
                (concat
                 "^[ \t]*"
                   "\\("
                     "\\("
                       "[Aa][Nn][Tt][Ww]\\.?\\|"     ; antw
                       "[Aa][Ww]\\|"                 ; aw
                       "[Ff][Ww][Dd]?\\|"            ; fwd
                       "[Oo][Dd][Pp]\\|"             ; odp
                       "[Rr][Ee]\\|"                 ; re
                       "[Rr][\311\351][Ff]\\.?\\|"   ; ref
                       "[Ss][Vv]"                    ; sv
                     "\\)"
                     "\\(\\[[0-9]*\\]\\)"
                     "*:[ \t]*"
                   "\\)"
                 "*[ \t]*"
                 ))

message-subject-trailing-was-query
     表題の行にぶら下がっている (was: <古い表題>) をどうするかを制御します。nil だったら表題をそのままにしておきます。ask というシンボルだったら、どうするかを利用者に尋ねます。表題が message-subject-trailing-was-ask-regexp に合致する場合だけですが。message-subject-trailing-was-query が t だったら、常にぶら下がった古い表題をはぎ取ります。その場合は message-subject-trailing-was-regexp が使われます。

message-alternative-emails
     あなたの第二、第三のメールアドレスに合致する正規表現です。元の記事の To、 Cc または From ヘッダーにあって、この変数に合致する最初のアドレスが、ディフォルトの From の値を置き換えて、出て行くメッセージの From 欄として使われます。

     例えばあなたが john@home.net および john.doe@work.com という第二の電子メールアドレスを持っていて、それらに宛てて送られてきたメッセージに返信するときに、それらを From 欄で使いたければ、この変数を次のように設定すれば良いでしょう:

          (setq message-alternative-emails
                (regexp-opt '("john@home.net" "john.doe@work.com")))

     この変数は、投稿様式 (posting styles) や message-setup-hook を実行することによって設定されるどんなものよりも優先します。

message-allow-no-recipients
     Gcc と Fcc 以外に受取人がいなかった場合 (訳注: To, Cc, Newsgroups などが空だった場合) に、何をするかを設定します。 always だったら送信できますが、never だったら送信できません。ask (それがディフォルト) だったら、どうするかを尋ねられます。

message-hidden-headers
     正規表現、正規表現のリスト、または最初の要素が not で残りが正規表現であるリストです。メッセージを作成しているときに、どのヘッダーを隠したままにしておくかを決めます。

          (setq message-hidden-headers
                '(not "From" "Subject" "To" "Cc" "Newsgroups"))

     それらのヘッダーは、それら以外の部分にバッファーを狭めること (narrowing) によって隠されます。M-x widen を使うことによって、それらが見えるようにすることができます。

message-header-synonyms
     似た意味を持つヘッダー名のリストのリストです。例えばこのリストが Cc と To を要素に持つリストを含んでいると、メッセージがすでに受信者に Cc されている場合、 message-carefully-insert-headers は To ヘッダーを挿入しません。

メールヘッダー
=======

message-required-mail-headers
     この変数の構文については News Headers を参照してください。ディフォルトは (From Subject Date (optional . In-Reply-To) Message-ID (optional . User-Agent)) です。

message-ignored-mail-headers
     メールを出す前に取り除かれるヘッダーの正規表現です。ディフォルトは

     ^[GF]cc:\\|^Resent-Fcc:\\|^Xref:\\|^X-Draft-From:\\|

     ^X-Gnus-Agent-Meta-Information: です。

message-default-mail-headers
     この文字列はメールとして初期化されたすべてのメッセージバッファーの、ヘッダーの最後尾に挿入されます。

message-generate-hashcash
     メッセージのための X-Hashcash ヘッダーを計算して付加すべきかどうかを指示する変数です。See Hashcash (The Gnus Manual).  opportunistic にすると、ユーザーを待たせない場合に限り、ヘッダーを作ります。

メール変数
=====

message-send-mail-function
     現在のバッファーをメールとして送るために使われる関数です。ディフォルトは message-send-mail-with-sendmail、またはシステムによっては smtpmail-send-it です。他に message-send-mail-with-mailclient, message-send-mail-with-mh, message-send-mail-with-qmail, message-smtpmail-send-it および feedmail-send-it が使えます。

     関数 message-send-mail-with-sendmail は記事を順番待ちに入れたり (queuing) 送信するために、記事を sendmail コマンドにパイプします。ローカルシステムが sendmail でメールを送信するように設定されていなくても、遠隔 SMTP サーバーに接続することができるのであれば、message-send-mail-function を smtpmail-send-it に設定することができます。smtpmail パッケージを使うために正しい設定がなされているかどうか確認してください。例です:

          (setq message-send-mail-function 'smtpmail-send-it
                smtpmail-default-smtp-server "YOUR SMTP HOST")

     これと似たものに message-smtpmail-send-it があります。 ISP が POP-before-SMTP の認証を要求する場合に有用です。See POP before SMTP (The Gnus Manual).

message-mh-deletable-headers
     ほとんどの版の MH は、この変数に設定されているヘッダーを含んでいるメッセージを食わされるのを嫌います。この変数が nil でない (これがディフォルトですが) なら、これらのヘッダーは MH を介してメッセージを送る前に取り除かれます。あなたの MH がこれらのヘッダーを扱うことができるのであれば、 nil に設定してください。

message-qmail-inject-program
     qmail-inject プログラムがある場所です。

message-qmail-inject-args
     qmail-inject プログラムに渡す引数です。これは文字列のリストで、それぞれの引数は一つの文字列でなければなりません。これは関数でも構いません。

     例えば、メールが弾かれてしまった場合の正しい戻り先を指定したり、メーリングリストのサーバーのアドレスの仕様規定に対処するために“envelope sender” のアドレスを設定したい場合は、この変数を '("-f" "you@some.where") にすれば良いでしょう。

     訳注:“envelope sender”はメールを送信するときに MTA に渡す真の送信者のアドレスで、ヘッダーの From: 行に書くものとは別です。

message-sendmail-f-is-evil
     nil ではない値にすると、sendmail のコマンド行に -f username を付加しません。そうすることは、付加するようにしておくより邪悪ですらあるでしょう。

     訳注: ディフォルトでは“envelope sender”を指定するために付加します。 sendmail のディフォルトの動作では、それを指定されると「真の送信者が書き換えられた」という意味にも解釈されることが書かれた X-Authentication-Warning: ヘッダーを追加します。

message-sendmail-envelope-from
     message-sendmail-f-is-evil が nil のとき、この文字列で SMTP エンベロープで使うアドレス (“envelope sender”) を指定します。nil だったら user-mail-address を使います。 header というシンボルだったら、メッセージの From ヘッダーを使います。

message-mailer-swallows-blank-line
     システムのメイラーがヘッダーと本文を一緒にしてしまう場合は nil ではない値に設定してください。(SunOS 4 において sendmail がリモートモードで動作する場合が該当します。) 値は、障害が実際に起きるかどうかをテストするための式にすべきです。

     訳注: 具体的には、本文の第一行目以降にヘッダーのようなテキストがあると、それらがヘッダーの一部だと見なされてしまう問題です。

message-send-mail-partially-limit
     message/partial として送信されるメッセージのサイズの制限です。それを越えたらメッセージを分割して送るべきメッセージの大きさの下限を、文字数で換算した値です (訳注: 日本語的には「下限」ではなく「上限」)。nil だったら (それがディフォルトです)、サイズは無制限になります。

ニュースヘッダー
========

message-required-news-headers はヘッダーのシンボルのリストです。これらのヘッダーは自動的に作成されるか、もしくはそれが不可能であれば (訳注: 値が自動で定まらなければ)、利用者に入力してもらうことを要求します。以下のシンボルが使えます:

From
     この必須のヘッダーは message-make-from 関数によって作られます。それは変数 message-from-style, user-full-name, user-mail-address に依存します。

Subject
     この必須のヘッダーは、まだ存在しない場合は入力を求められます。

Newsgroups
     この必須のヘッダーは、記事を投稿するニュースグループを指定します。まだ存在しない場合は入力を求められます。

Organization
     このあっても無くても良いヘッダーは、message-user-organization 変数に応じた値が作られます。この変数が t だったら message-user-organization-file が使われます。この変数は文字列でも良いし (その場合はその文字列が使われます)、関数であっても構いません (その関数は引数無しで呼ばれ、文字列を返さなければなりません)。

Lines
     このあっても無くても良いヘッダーは Message が計算して作ります。

Message-ID
     この必須のヘッダーは Message によって作成されます。日付、時刻、 (ローカル部のための) 利用者名、およびドメイン部に基づいたユニークな ID です。ドメイン部については、有効な FQDN (完全に条件を満たしたドメイン名) らしいものが見つからない場合、message は message-user-fqdn, system-name, mail-host-address および message-user-mail-address (すなわち user-mail-address) を (この順で) 探します。

User-Agent
     このあっても無くても良いヘッダーは、ローカル変数 message-newsreader に従って作られます。

In-Reply-To
     このあっても無くても良いヘッダーは、返答しようとしている記事の Date と From ヘッダーを元に作られます。

Expires
     このあろうが無かろうが本当にどうでも良いヘッダーは、 message-expires 変数に従って挿入されます。これを使うことは強く非難されているので、自分が何をしているかをわかっていないなら、使うべきではありません。

Distribution
     このあっても無くても良いヘッダーは、 message-distribution-function 変数が指定する関数が作ります。これを使うことは非難されていて、非常に誤解されたヘッダーです。

     訳注: message-distribution-function のディフォルト値は nil なので、そのままではこれを指定しても Distribution: ヘッダーは挿入されません。C-c C-f C-d 命令を使って、手で記入することはできます。ただし配送範囲の制限はニュースサーバーが管理すべきであって、利用者が記入する必要は普通は無いはずです。

Path
     このあろうが無かろうが本当にどうでも良いヘッダーは、おそらく決して (利用者が) 使ってはいけないものです。しかしいくつかの とても 古いサーバーは、このヘッダーが存在することが必要なのです。 message-user-path 変数が、この Path ヘッダーをどういう見栄えにするかをさらに制御します。nil だったらサーバー名を端点 (leaf node) として使います。文字列だったら、その文字列を使います。それが文字列でも nil でもなかったら、利用者の名前だけを使います。しかし、この変数をいじくらなければならなくなる機会は非常に少ないでしょう。

加えて、このリストに cons を入れることができます。この cons の CAR はシンボルでなければなりません。このシンボルの名前はヘッダー名です。また CDR は、このヘッダーの値としてそのまま入れられる文字列か関数のどちらかです。例えば Mime-Version: 1.0 を挿入したい場合は、リストに (Mime-Version . "1.0") を入れなければなりません。もし滑稽な引用文を挿入したいのなら、(X-Yow . yow) のようなものをリストに入れることができるでしょう。そうすると、関数 yow が引数無しで呼ばれます。

CAR が optional である cons をリストが含んでいる場合は、その cons の CDR が nil でないときだけ (その CDR が) 挿入されます。

このリストからある項目を消したいときは、以下の Lisp の切れ端が役に立つでしょう。他の要素を削除したいときはそれに合わせてください。

     (setq message-required-news-headers
           (delq 'Message-ID message-required-news-headers))

出て行くニュース記事をカスタマイズするための他の変数:

message-syntax-checks
     出て行くメッセージの、どの構文の検査をすべきではないかを制御します。例えば、長い署名の検査を禁止するには、このリストに

          (signature . disabled)

     を加えてください。

     有効な検査は以下の通りです (訳注: これらの検査の一部はメールでも行なわれます):

     approved
          記事に Approved ヘッダーがあるかどうかを調べます。それは司会者のような人だけが含めるはずのものです。

     continuation-headers
          空白で始まらない継続したヘッダー行があるかどうかを調べます。

     control-chars
          使ってはいけない文字を調べます。

     empty
          記事が空かどうかを調べます。

     existing-newsgroups
          Newsgroups と Follouup-to ヘッダーに記入されているニュースグループが存在するかどうかを調べます。

     from
          From ヘッダーがまともかどうかを調べます。

     illegible-text
          本文に印字できない文字があるかどうかを調べます。

     invisible-text
          バッファーに見えないテキストがあるかどうかを調べます。

     long-header-lines
          長すぎるヘッダー行を調べます。

     long-lines
          本文の中の長すぎる行を調べます。

     message-id
          Message-ID が構文的にまともかどうかを調べます。

     multiple-headers
          複数の同じヘッダーの存在を調べます。

     new-text
          メッセージに新しい文があるかどうか (訳注: 引用ばかりでないかどうか) を調べます。

     newsgroups
          空でない Newsgroups ヘッダーがあるかどうかを調べます。

     quoting-style
          最後の引用部分に続くテキストがあるかどうかを調べます。

     repeated-newsgroups
          Newsgroups と Followup-to ヘッダーで、同じグループ名が繰り返し使われているかどうかを調べます。

     reply-to
          Reply-To ヘッダーがまともかどうかを調べます。

     sender
          From ヘッダーが変だったら、新しい Sender ヘッダーを挿入します。

     sendsys
          Sendsys: か Version: ヘッダーがあるかどうかを調べます (訳注: いずれもニュースの管理人だけが使うものです)。

     shoot
          Message-ID ヘッダーのドメイン項がまともかどうかを調べます。

     shorten-followup-to
          投稿するグループの数を Followup-to ヘッダーを付け加えることによって少なくするかどうかを調べます (訳注: 複数のニュースグループに投稿する記事に Followup-to ヘッダーが無い場合に発動され、 Followup-to ヘッダーに記入する値の入力を要求します)。

     signature
          署名の長さを調べます。

     size
          サイズが大きすぎないかどうかを調べます。

     subject
          空でない Subject ヘッダーがあるかどうかを調べます。

     subject-cmsg
          ニュースのコントロールメッセージのような表題があるかどうかを調べます。 (訳注: 表題が cmsg で始まるもので、ニュースの管理人だけが使います。一般の利用者がニュース記事の取り消し (cancel) を行なうときにも使いますが、その場合は、この検査を通らずに、それ専用の枠組みで実行されます。)

     valid-newsgroups
          Newsgroups と Followup-to ヘッダーが構文的に正しいかどうかを調べます。

     ディフォルトでは、これらすべての条件が調べられます。ただし message-insert-canlock が nil だったらディフォルトでは検査が行なわれない sender を除きます。See Canceling News.

message-ignored-news-headers
     投稿する前に取り除かれるヘッダーの正規表現です。ディフォルトは

     ^NNTP-Posting-Host:\\|^Xref:\\|^[BGF]cc:\\|^Resent-Fcc:\\|

     ^X-Draft-From:\\|^X-Gnus-Agent-Meta-Information: です。

message-default-news-headers
     この文字列はニュースとして初期化されたすべてのメッセージバッファーの、ヘッダーの最後尾に挿入されます。

ニュース変数
======

message-send-news-function
     現在のバッファーをニュースとして送るために使われる関数です。ディフォルトは mesage-send-news です。

message-post-method
     できあがったニュースメッセージを投稿するために使われる Gnus の「選択方法」 (詳細は Gnus マニュアルを見てください) です。

挿入するための変数
=========

message-cite-style
     返信するときに使う総体的な様式です。引用と返信文の位置関係をどうするか、どんな形式で引用するか、シグネチャをどこに置くか、というような物事をこれで決定します。

     値は nil (どの変数も覆しません) またはディフォルト値を覆すための (VARIABLE VALUE) というペアの let 型リストのどちらかです。

     特定のグループのためにこの変数を設定するには gnus-posting-styles を参照してください。よく使われているいろいろなメール・エージェントをまねた設定が message-cite-style-* という変数に用意されています。

message-cite-reply-position
     返信文をどこに置くかを指定します。使うことができる様式には、インラインで返信するための traditional、先頭に返信文を書く (top-posting) ための above、および文末に返信文を書くための below があります。

message-ignored-cited-headers
     この正規表現に合致するすべてのヘッダーが、引用のために yank されたメッセージから取り除かれます。ディフォルトは . で、すべてのヘッダーが取り除かれると言うことです。

message-cite-prefix-regexp
     行の引用接頭語として見なすことができるものに最大限に合致する正規表現です。

message-citation-line-function
     引用行を挿入するために呼ばれる関数です。ディフォルトは message-insert-citation-line で、これは引用行を次のようにします:

          Hallvard B Furuseth <h.b.furuseth@usit.uio.no> writes:

     この関数が呼ばれたとき、ポイントはメッセージの本文の先頭に置かれるでしょう。

     なお Gnus には、`writes:' の上でクリックすると引用されたテキストを隠す機能があります。もしあなたが度を越して引用行を変更してしまうと、それを読む人たちも彼らの Gnus を対応させなければならなくなるでしょう。変数 gnus-cite-attribution-suffix を参照してください。詳細は see 記事のハイライト (The Gnus Manual), にあります。

message-yank-prefix
     記事に返答かフォローアップをするときは、普通はあなたが応答しようとしている人を引用したいでしょう。引用文の挿入は“yank”することによって行なわれ、それぞれの yank された行の前に message-yank-prefix が付けられます (すでに引用符 message-yank-cited-prefix が付いている行と、 message-yank-empty-prefix が付けられた空行は対象外です)。ディフォルトは >  です。

message-yank-cited-prefix
     すでに引用されたテキストを含む記事から yank するとき、それぞれの行にはこの変数の値が前置されます。ディフォルトは > です。 message-yank-prefix も参照してください。

message-yank-empty-prefix
     記事からテキストを引用するとき、それぞれの空行にこの変数の値が前置されます。ディフォルトは > です。この変数を空文字に設定することによって、引用されたテキストを自動的に段落分けすることができます。 message-yank-prefix も参照してください。

message-indentation-spaces
     Yank されたメッセージを字下げするための空白の数です。

message-cite-function
     元記事を引用するための関数です。ディフォルトは message-cite-original で、これは単純に元のメッセージを挿入して、それぞれの行の頭に >  をくっ付けます。 message-cite-original-without-signature は同様のことをしますが、署名を省きます。

message-indent-citation-function
     メールバッファーに挿入された引用文を修正するための関数です。これは関数のリストであることもできます。それぞれの関数は (point) と (mark t) の間で引用を見つけることができます。そしてそれぞれの関数は、修正された引用文の周り (の修正前と同等の場所) にポイントとマークが置かれたままになっているようにしなければなりません。

message-mark-insert-begin
     挿入された何らかのテキストの始まりに、印を付けるための文字列です。

message-mark-insert-end
     挿入された何らかのテキストの終りに、印を付けるための文字列です。

message-signature
     メッセージバッファーの最後に挿入される文字列です。もし t (これがディフォルトです) であれば、ファイル message-signature-file が代わりに挿入されます。もし関数であれば、関数の結果が代わりに使われます。もし式であれば、式の結果が変わりに使われます。この変数が nil だったら、署名はまったく挿入されません。

message-signature-file
     バッファーの最後に挿入される、署名の入っているファイルです。ディレクトリーが指定されていると、message-signature-directory の値はたとえ設定されていても無視されます。ディフォルトは ~/.signature です。

message-signature-directory
     署名ファイルを置くディレクトリーの名前です。そういうファイルをたくさん持っているならば、例えば投稿様式 (Gnus posting styles) でそれらを切り替える際に役立ちます。もし nil だったら (それがディフォルト)、 message-signature-file がディレクトリーも指定すると見なされます。

message-signature-insert-empty-line
     t (ディフォルト値) だったら、署名と本文を分離する記号の前に空行が挿入されます。

RFC1036bis は、署名はその前に --  の三文字だけの行があるべきであると言っていることに注意してください。これは受け手が自動的に署名を認識して、処理をすることを簡単にするためです。ですから、その、あなたの美しいデザインを、それが台無しにしていると感じても、それらの文字を取り除かないでください。

署名は四行より多くなるべきでは無いと言うことも注意してください。 ASCII の絵を入れることは、皆にあなたが馬鹿で何も重要なことは言わないということを信じさせるための効果的な方法です。

いろいろなメッセージ変数
============

message-default-charset
     MIME 文字セット名のシンボルです。メッセージ内の非-ASCII 文字は、この文字セットを使ってエンコードされることになっています。ディフォルトは MULE 機能が無い Emacsen では iso-8859-1 です。それ以外では nil で、利用者に尋ねることを意味します。(この変数は MULE 機能が無い Emacs でのみ使われます。) MULE から MIME への置き換え処理の詳細は see 文字セットの変換 (Emacs MIME Manual), を参照してください。

message-fill-column
     メッセージバッファーで行がこの桁数を越えると自動的な折り返しを起こすべき、バッファーローカルな値です。nil ではない値 (ディフォルト) でメッセージバッファーの自動折り返しが ON になります。

message-signature-separator
     署名と本文を分離する記号に合致する正規表現です。ディフォルトは ^-- *$ です。

mail-header-separator
     ヘッダーを本文から分けるために使われる文字列です。ディフォルトは --text follows this line-- です。

message-directory
     メールに関係する多くの処理で使われるディレクトリーです。ディフォルトは ~/Mail/ です。メールに関する他のファイル名やディレクトリー名を指定する変数の値は、この message-directory の値を基点にして派生します。

message-auto-save-directory
     Gnus が動作していないときに Message がバッファーを自動保存するディレクトリーです。nil だったら Message は自動保存を行ないません。ディフォルトは ~/Mail/drafts/ です。

message-signature-setup-hook
     メッセージバッファーを初期化するときに実行されるフックです。それはヘッダーが挿入された後の、まだ署名が挿入されていないときに実行されます。

message-setup-hook
     メッセージバッファーを初期化する処理の最後に、まだ yank される文章が挿入されていないときに実行されるフックです。

message-header-setup-hook
     ヘッダーを初期化した後に、ヘッダーに範囲を狭めて呼ばれるフックです。

     例えば、Gnus を実行していて、すべてのニュース記事とメーリングリストに送るすべてのメッセージに Mail-Copies-To ヘッダーを挿入したいのであれば、以下のようなことができます:

          (defun my-message-header-setup-hook ()
            (let ((group (or gnus-newsgroup-name "")))
              (when (or (message-fetch-field "newsgroups")
                        (gnus-group-find-parameter group 'to-address)
                        (gnus-group-find-parameter group 'to-list))
                (insert "Mail-Copies-To: never\n"))))

          (add-hook 'message-header-setup-hook
                    'my-message-header-setup-hook)

message-send-hook
     メッセージを送る前に実行されるフックです。

     もし送る前に特定のヘッダーを加えたいのであれば、 message-add-header 関数をこのフックに使うことができます。例えば:

          (add-hook 'message-send-hook 'my-message-add-content)
          (defun my-message-add-content ()
            (message-add-header "X-In-No-Sense: Nonsense")
            (message-add-header "X-Whatever: no"))

     この関数は、そのヘッダーがすでに存在している場合はヘッダーを加えません。

message-send-mail-hook
     メールメッセージを送る前に実行されるフックです。このフックは非常に遅い時期---メッセージがメールとして実際に送信される直前---に実行されます。

message-send-news-hook
     ニュースメッセージを送る前に実行されるフックです。このフックは非常に遅い時期---メッセージがニュースとして実際に送信される直前---に実行されます。

message-sent-hook
     メッセージを送った後で実行されるフックです。

message-cancel-hook
     ニュース記事の取り消し (cancel) を行なうときに実行されるフックです。

message-mode-syntax-table
     メッセージモードのバッファーで使われる構文テーブルです。

message-cite-articles-with-x-no-archive
     非-nil だったら、X-No-Archive が設定されている記事から引用されたテキストを取り除きません。この変数が nil になっていても、 undo のキー操作を行なうことによって取り除かれたテキストを元に戻すことができます。

message-strip-special-text-properties
     Emacs はメッセージ作成をいろいろに壊してしまうことができる多くの特別なテキスト属性 (text properties) を持っています。この変数が非-nil に設定されていると、message はそれらの属性をメッセージを作成するバッファーから剥ぎ取ります。しかしいくつかのパッケージは、動作するためにそれらの属性が存在していることが必要です。それらのパッケージの一つを使うのならば、このオプションを off にして、メッセージが壊れてしまわないことを祈ってください。

     訳注: 日本語入力のためのパッケージである tamago 第四版は、まさにテキスト属性を巧みに駆使しています。そのため、この変数が非-nil に設定されていても、message は tamago が使うテキスト属性だけは特別扱いして、剥ぎ取らないようになっています。

message-send-method-alist
     メッセージを送出するための方法を指定する連想リストです。それぞれの要素は次の形式になっています:

          (TYPE PREDICATE FUNCTION)

     type
          方法の呼称を指定するシンボルです。

     predicate
          そのメッセージが TYPE の型のメッセージであるかどうかを判定するために、引数無しで呼ばれる関数です。関数はそのメッセージがあるバッファーで呼び出されます。

     function
          PREDICATE が nil ではない値を返したときに呼ばれる関数です。 FUNCTION は一つの引数---接頭引数 (訳注: C-c C-c 命令に先立って与えられた接頭引数)---と共に呼ばれます。

     ディフォルトは次のようになっています:

          ((news message-news-p message-send-via-news)
           (mail message-mail-p message-send-via-mail))

     message-news-p 関数はそのメッセージがニュース記事のように見える場合に nil ではない値を返し、message-send-via-news 関数は message-send-news-function 変数 (see News Variables) に設定された関数を呼び出して、そのメッセージを送信します。 message-mail-p 関数はそのメッセージがメールのように見える場合に nil ではない値を返し、message-send-via-mail 関数は message-send-mail-function 変数 (see Mail Variables) に設定された関数を呼び出して、そのメッセージを送信します。

     message-send-method-alist の各要素は先頭から順にすべて試されるので、例えば有効な Newsgroups: ヘッダーと To: ヘッダーの両方を持っているメッセージは、まずニュースとして送信された後にメールとしても送信されます。

送るための変数
=======

message-fcc-handler-function
     出て行く記事を保存するために呼ばれる関数です。この関数は記事を格納するためのファイル名と共に呼ばれます。ディフォルトの関数は Unix mailbox 様式で保存する message-output です。

message-courtesy-message
     複合メッセージ (訳注: ニュースとメールの両方で送信するメッセージ) を送るときに、この文字列がメールで送られる複製の方の本文の先頭に挿入されます。もしその文字列が %s 書法仕様を含んでいたら、記事が投稿されたニュースグループがそこに挿入されます。この変数が nil だったら、そのような親切メッセージは加えられません。ディフォルト値は "The following message is a courtesy copy of an article\nthat has been posted to %s as well.\n\n" です。

message-fcc-externalize-attachments
     nil だったら、Fcc で保存するメッセージのコピーに通常のパートとしてファイルを添付します。非-nil だった場合は、外部パートとしてローカルファイルを添付します (訳注: そのパートをローカルファイルに書き出して、メッセージにはそのファイルの格納場所を示すタグだけを含んでいるパートを付けます)。

message-interactive
     nil でなかったら、メッセージを送信するときにエラーが出るのを待って表示します。nil だったら、エラーの報告をメールで行ないます。

message-confirm-send
     nil でなかったら、Gnus はメッセージを送信するときに確認を求めます。

メッセージバッファー
==========

Message はあなたがメッセージバッファーを要求したときに、ユニークな (唯一無二の) バッファー名で新しいバッファーを作ります。メッセージを送ったときに、バッファーは普通は削除されません。その名前は変更されて、特定の数の古いメッセージバッファーが残されます。

message-generate-new-buffers
     メッセージを書くために新しいメッセージバッファーを作るかどうかを制御します。次の値が有効です:

     nil
          メッセージのやり方でバッファーの名前を生成 (例えば *mail*, *news*, *mail to whom*, *news on group* など) して、その名前の既存のバッファーで編集を続行します。そのようなバッファーが無い場合は、新たに作られます。

     unique

     t
          メッセージのやり方で生成された名前で新しいバッファーを作ります。

     unsent
          unique に似ていますが、バッファー名が "*unsent " で始まります。

     standard
          nil に似ていますが、*mail message* のような、より単純なバッファー名になります。

     function
          もしこれが関数だったら、その関数を三つの引数---その型、送り先のアドレス、グループ名---と共に呼びます (これらのどれもが nil でありえます)。その関数は新しいバッファー名を返さなければなりません。

     ディフォルト値は unsent です。

message-max-buffers
     この変数はどのくらい古いメッセージバッファーを残しておくかを指定します。これより多いメッセージバッファーがあれば、一番古いバッファーが削除されます。ディフォルトは 10 です。この変数が nil だったら、古いメッセージバッファーは削除されません。

message-send-rename-function
     メッセージを送った後で、バッファーの名前は、例えば *reply to Lars* から *sent reply to Lars* に変更されます。もしこれが好きではないのならば、この変数をあなたの好きな方法でバッファーの名前を変更する関数に設定してください。そもそもバッファー名を変更することを好まないのであれば、次のようにすれば良いでしょう:

          (setq message-send-rename-function 'ignore)

message-kill-buffer-on-exit
     nil でなければ、終了時にすぐにバッファーを削除します。

メッセージが請け負う仕事
============

Message がニュース/メールリーダーから使われているときに、リーダーにはメッセージが送られた後で行なう何らかの仕事が課せられることがよくあります。おそらく前のウィンドウ配置に戻したり、記事にそれが返答されたことを表す印を付けるようなことでしょう。

利用者はいろいろな方法でメッセージバッファーを終わらせることができます。最も良くあるのは C-c C-c で、それはメッセージを送って終了します。他の可能性としては C-c C-s があります。これはメッセージを送るだけです。C-c C-d はメッセージを後で編集することにして、メッセージバッファーを bury-buffer します (訳注: それを Emacs 上に存在するバッファーのリストの最後の要素にして隠します)。そして C-c C-k はメッセージバッファーを削除します。これらのそれぞれの動作は、それらと関連付けられた請け負い仕事を含んでいるリストを持っています。そのリストは message-send-actions, message-exit-actions, message-postpone-actions および message-kill-actions です。

Message はこれらのリストを操作するために message-add-action 関数を用意しています。第一引数は加えられる請け負い仕事で、残りの引数はどのリストにこの請け負い仕事を加えるかを指定します。これは Gnus から使う例です:

       (message-add-action
        `(set-window-configuration ,(current-window-configuration))
        'exit 'postpone 'kill)

これはメッセージバッファーが削除 (kill)、延期 (postpone)、終了 (kill) されたときに、Gnus のウィンドウ配置を復活させるためのものです。

第一引数に与える「請け負い仕事」は次のどれかです: 普通の関数、 car が関数で CDR が引数のリストであるリスト、または eval (評価) される式です。

訳注: たぶん実際のソースコードを見た方が話が早いでしょう。

互換性
***

Message は事実上それ自身の変数しか使わず (*)、古い mail- 変数は考慮に入れません。これらの変数を Message が考えに入れるようにさせたいのであれば、以下のものを .emacs ファイルに入れれば良いでしょう:

     (require 'messcompat)

これは多くの Message 変数を、それらに対応する mail- 変数の値に基づいて初期化します。

訳注*: 実際には随所で Gnus の変数を使っています。世の中うまくいきません。

付記
**

応答
==

メッセージがどこに行くかを決定するために、ディフォルトでは以下のアルゴリズムが使われます。

reply
     「返答」(reply) は、メッセージを送った人 だけ にメールで応答したいときのものです。受取人は一人しかいません。受取人が誰であるかを決定するために、以下のヘッダーを順番に調べます:

     Reply-To

     From

wide reply
     「広い返答」(wide reply) は、応答しようとしているメッセージに書かれていた すべての 人々へのメールによる応答です。以下のヘッダーから抽出したすべてのメールアドレスを連結して、出て行く To/Cc ヘッダーを作ります:

     From
          (Reply-To が無い限りこれが使われますが、ある場合は代わりにそれが使われます)。

     Cc

     To

     Mail-Copies-To ヘッダーが存在していたならば、それも宛先のリストに加えられます。このヘッダーが never だったら、From (または Reply-To) のメールアドレスを除外しなければならないということです。

followup
     「フォローアップ」(followup) はニュースで送る応答です。以下のヘッダー (優先順位が高い順に並んでいます) で、どこに応答を送るかを決定します:

     Followup-To

     Newsgroups

     もし Mail-Copies-To ヘッダーがあったならば、それが never でない限り、新しい Cc ヘッダーの基として使われます。

GNU フリー文書利用許諾契約書
****************

訳注: 非公式な日本語訳 (http://www.opensource.jp/fdl/fdl.ja.html.euc-jp) があります。

     [file doclicense.texi not included]