Chienomi

e-mail CCとToその使い分けと歴史的経緯

文化::history

序

くわっちょ@社畜犬氏のこのツイート

メールのccやbccってオッサン文化なのか？ ccやbccの使い方に悩む若い人達を見て思った。

をうけてアンケートをとってみた。 たくさんに方にお答えいただき深く感謝する。

Twitterでのアンケート結果

eメールの元々のto, ccの仕様知ってる人はTwitterでもいないんじゃなかろうか。 試しにアンケートとって見ようかな。

【問】eメールのto, cc、その本来の使い分けは;

さて、

  1. 目上の人がto, それ以外がcc

を選んだあなた!! 現代社会に毒されすぎだぞ!

  1. 主たる送信相手がto,メモとしての回覧がcc

を選んだあなた!! 現代的なインターネットピーポーだな!?

  1. 単に1番目のアドレスがto, 2番目がcc

を選んだあなた!! さてはToに複数の設定ができないクソメーラーを使っていたインターネット老人会員だな!?

  1. 外部の人がto, 内部の人がcc

を選んだあなた!! eメールが使われる場面がもっと広いと知ったほうがいいぜ!!

で、まぁ、正解としては、「インターネットe-mail」に限れば2なのだが、「e-mail全体」で言うならば3である。 ただ、ニュアンスが正確ではないので、「正解がないよ!!」と思った方には大変申し訳無い。 そのものズバリの内容を書いてしまうと違和感がありすぎてバレバレなので。

なお、これ、最初1がとても伸びていてとても不安だったのだけど、最終的には1が一番少なくなったので安心している。

また、3を単純に「宛先が複数あるときに、ひとつだけToに入れる」というふうに解釈した人もいるかもしれない、というよりもわざと現代のインターネットピーポーはそう解釈する書き方をしたのだが、3はそうではなくて、「同じ人の宛先で、その人の最初のアドレスがTo、2番目以降のアドレスがcc」という意味である。

前提

まず、この話を理解するには、次のことを知っている必要がある。

  • MTAはメールヘッダーを原則として見ない。 To, CC, BCCいずれもRCPT TOにまとめられる。そのため、このヘッダーはあくまでUAのものである
  • e-mailはIPより以前にUUCPにおいて使われていた
  • eメールのRFCはRFC822、及びそれを置き換えたRFC2822が有名だが、それ以前にRFC733がある。また、RFC561, RFC524もあり、関連としてRFC821もある (その他アップデートとかもいっぱいある)
  • RFC561はFTP経由でメールをやりとりするものである
  • RFC733はSMTP経由のメールのもので、これはIPでもUUCPでも使われた
  • RFC733の発行は1977年。RFC822は1982年
  • 昔はeメールは、メールのあるマシンにログインして、そのマシンの中で読み書きするものだった。手元にマシンに取り込む方法(POP3)ができるのはずっと後 (POP3は1996年、IMAP4は1994年、初代のPOPは1984年)

in RFC

RFC733には次のように書かれている。

optional-field  =
               "To"         ":" #address
            /  "cc"         ":" #address
            /  "bcc"        ":" #address    ; Blind carbon
            /  "Subject"    ":" *text
            /  "Comments"   ":" *text
            /  "Message-ID" ":" mach-id     ; Only one allowed
            /  "In-Reply-To"":" #(phrase / mach-id)
            /  "References" ":" #(phrase / mach-id)
            /  "Keywords"   ":" #phrase
            /  extension-field              ; To be defined in
                                            ;  supplemental
                                            ;  specifications
            /  user-defined-field           ; Must have unique
                                            ;  field-name & may
                                            ;  be pre-empted

一方、RFC822ではこうだ。

     destination =  "To"          ":" 1#address  ; Primary
                 /  "Resent-To"   ":" 1#address
                 /  "cc"          ":" 1#address  ; Secondary
                 /  "Resent-cc"   ":" 1#address
                 /  "bcc"         ":"  #address  ; Blind carbon
                 /  "Resent-bcc"  ":"  #address

だから、規格上は「ToはPrinmary、CCはSecondary」である。 RFC822では次のように説明されている。

  4.5.1.  TO / RESENT-TO
     
        This field contains the identity of the primary recipients  of
        the message.
     
     4.5.2.  CC / RESENT-CC
     
        This field contains the identity of  the  secondary  (informa-
        tional) recipients of the message.

ところが、RFC733には単にそれがないだけではない。 説明も少し異なっている。

a.  To

    This field contains the identity of the primary recipients of
    the message.

b.  cc

    This field contains the identity of the secondary  recipients
    of the message.

RFC822では「お知らせの宛先だよ」と書いてあるけれども、RFC733ではsecondaryとしか書いていない。 実はこの間に、このニュアンスはちょっと変わっている。

UUCP

アメリカで商用インターネットが開始したのは1982年で、それ以前というとUUCPネットワークのUSENETのほうが一般的だった(といっても、普通の人は使わないけど)。

UUCPではアドレスは example.site!foo!bar!mike みたいに書くものである。 これは、「伝送経路を書かなければならない」のだ。インターネットアドレスの場合、グローバルに引くことができるので、宛先ひとつで伝送できてしまうのだが、UUCPに関しては「直接接続しているお隣のマシンの名前を書き連ねる」必要がある。 この場合、自分のマシンからexample.siteに伝送して、example.siteがfooに伝送して、fooがbarに伝送し、barはmikeのメールボックスに配送する。

そして、当時はネットワークはものすごく不安定だった。マシンやホストが応答しないのはごく当たり前で、メールが届かないことなんてごく普通にあったのだ。

おわかりいただけただろうか

UUCPでは経路を書く必要があり、なおかつ経路は非常に不安定で届かない可能性が高い。 そうなったときにどうするだろうか。

そう、複数の経路を書くのだ。

IPよりもUUCPが有力視されていた時代、メールは「送達の確実性を上げるにはどうしたらいいか」ということに苦心していた。 それが、8ビット目のマスクだったりするのだが、ひとつの宛先に対して複数の経路で遅れば送達の確実性は上がる。 だから、

To: example.site!foo!bar!mike
cc: exmaple.edu!baz!bar!mike

みたいに書いていたのである。同様に複数に送る場合も

To: example.site!foo!bar!mike,exmaple.site!foo!quux!john
cc: exmaple.edu!baz!bar!mike,example.edu!quuux!quux!john,mycompany!bigcompany!smallcompany!quux!john

というわけだ。だから、1番目の宛先がToで、2番目以降の宛先がccになる。

もちろん、この使い方が全てではない。特に、メーリングリストにおける扱いの差も大きい。 前述のようにメールヘッダーはUAが扱うものであり、UAの振る舞いとしての利便性という問題もあった。 最も大きいのは、「返信したときに、自分以外のToやccは宛先に含まれるかどうか」だ。

今も行われるような、メーリングリストがToで、個人がCC、ということも行われていた。

だが、これは別に、RFC733で想定されていたということではなく、「ToとCCという、ふたつの宛先フィールドがあることを前提にしてMUAがどのように扱ったかということの結果生まれた文化」である。 そして、現実としてそっちのほうが普通だったし、伝送の問題が解決され、特にIPではその必要性がぐっと下がったことから、RFC822では現実での使われ方の方を優先して規格化したわけである。

前述のとおり、1982年には商用インターネットが開始し、もうその頃にはUSENETもインターネット経由で接続することが多くなっていた。RFC733がUUCP優勢の環境下でUUCPの頭で書かれたものであるのに対し、RFC822はIPの頭で書かれている。というよりも、RFC822によって置き換えたのは、UUCPのプロトコルからIPのプロトコルに転換するという意味合いも強かった。

よって、古く元々の、という意味では3. 「単に1番目のアドレスがto, 2番目がcc」が正しい。 ただ、私は「本来の」と書いてしまったので、規格上正しい、という意味にも取れてしまう。それだと現行規格上は2.「主たる送信相手がto,メモとしての回覧がcc」のほうが正しい。

そして、今はどのように扱うのが妥当かといえば、RFC822にある通り、2.「主たる送信相手がto,メモとしての回覧がcc」とするべきということになるだろう。 一般的にMUAは返信時に「自分以外のToはToに含めないが、CCはCCに残す」ことが多い点も留意したい。「当事者ではないが継続的に観測が必要なアドレス」はCCにしたほうが残る可能性が高いのだ (私が使っているClaws Mailは「全員に返信」しないと他のToもCCも関知しないので、CCにされても忘れがちだけども)。

また、「自分がToにいないメールに返信するとき」にどうなるかということも考えたほうが良いだろう。 (これについては考慮すべき要素は大変少ないが、それぞれのメールクライアントでどうなるか知っておくことは悪いことではない)

RFCのニュアンスについてもう少し言及すると、現代の感覚でRFC822だけを見れば、「secondary = informational」であると解釈しがちだ。だが、RFC733では前述の通りUUCPありきで複数のアドレスを書くことを想定していた。だから、primary, secondaryはそのまま「第一の」「第二の」アドレスなのである。

で、RFC822ではインターネット(IP)での利用を想定して「informationalな」アドレスであることが書き加えられた。これによって「secondary = informational」に見えるかもしれないが、実際はRFC733に”informational”を付け加えたものなので、「secondary」は依然として「第二の」アドレスである。だから、これは「第二の、あるいはinformationalな宛先」という解釈が妥当だろう。

指摘がある場合

私がインターネットに関わるようになったのは1991年からで、この経緯はリアルタイムに経験したわけではない (RFC733の規格化に関わったわけでもないし、ARPANETの中の人だったわけでもない。そもそも生まれる前の話である)。

あくまで文化研究の過程で得られた情報であり、この情報は誤りである可能性がある。

この事柄についてより詳細な情報をお持ちの方は、この記事のコメントに書いていただくか、マシュマロに書いていただくか、Twitterで私に直接言ってほしい。