Chienomi

cannonicalなeメールの書き方

文化::history

序

これは、伝統的(古典的)にeメールの書き方に関するeメール、マナーに関する話である。

これを書く理由としては、「eメールの正しい書き方」といってマナー講師が喧伝していた流儀を唯一絶対として声高に主張する声が大きすぎるからである。

そももそeメールはビジネスだけのものではないし、そんなことを言う人は確実にeメールがインターネットにおける主要使途であった時代を経験していない者であることは疑いようのないところであると思うが、マナー講師がでっちあげるでたらめをあざ笑うような人ですらもそんなことを恥ずかしげもなく主張するのは滑稽である。

実としてeメールにおいて守るべきことはいくつかあるのだが、それはおまけ程度に書くとして、ここはcanonicalなものを書くようにしよう。

予めお断りしておくが、ここで言うcanonicalなeメールの時代を私は経験してないし(多分日本にいた人は誰も経験していないし)、当時物の資料が乏しいため、絶対に正しいとは限らない。 より正確な資料や出典をお持ちの方はぜひコメントいただきたい。

canonicalなeメールの書き方

1行目と2行目

「冒頭に自分の名前を書き、続いて相手の名前を書く」というルールがある。

この理由は実は明らかではない。 RFC722以前のメール様式から引き継いでいる(要は自分が誰なのかということが本文でなければ示せない)ということや、MUAが本文を並べるとか色々な説明があるのだが、基本的にはMUAの事情として本文で示す必要があるということのようだ。

もうひとつ、伝送の問題がある。

eメールははるか古に生まれたものなので、サイト間通信が非常に不安定だった。 これは、“CC”の仕様の話でも触れたのだが、パリティビットの存在やCCによる複数経路の指定もその対策のひとつであった。

そして、正確に伝送されないことを考慮してのルールがこれだ。 伝送は当然ながら先頭から送られる。どこかでビットがずれてビット化けが発生するにしても、あるいは通信が切れてしまいロストするとしても、先にあるものほど正確な値を受け取りやすい。

ここで最も重要になる情報が、「誰からメールを受け取ったか」である。

Bobからメールを受け取ったが、途中で切れてしまっている、という場合、Bobに「メールが切れていたよ」と連絡することができる。 あるいは、それが重要なメールである可能性について考えるヒントにもなる。

次いで重要なのは、受け手が誤りでないことを示すための宛名であり、これを続けて書くわけだ。

簡潔に書く

先頭に自分の名前を書かなければならないほど伝送に問題があったのだから、 当然ながらメールは長くなればなるほど正しく伝送されない確率は上がる。

だから、全体を短く書き、重要なことほど先に書くのである。

どれくらい簡潔かというと、こんな感じ

Robart.
This is John.

meet at 9 a.m.
con room 2.

---
John

私の感覚では、今のLINEなんかよりずっと短い。 初期のショートメッセージ(8bitで20文字まで)くらいの感じだ。

ただ、常にこれくらい短かったわけではなく、USENETの投稿とかはそれなりに長い。 忠実に本質的情報だけを(駅の伝言板のように)書いたのはかなり限られたケースだったと見受けられる。

ただ、余計なことを書くなというのは基本的なことであり、形式的な文言は嫌われた。 実際、日本でも2010年くらいまではビジネス上でeメールの良い点として「形式的な内容に手間をとられず本質的な内容だけ書けば良いから能率的である」ということが挙げられていた。

78 columns

eメールは仕様として、1行あたりCRLFを除いて78 columns(つまり、CRLFを含めて80columns)に制限されている。

これを正しく理解できていない人が多いので説明しておこう。

そもそもこのルールは大ヒットスクリーン端末VT100が通常80桁であったことに由来する。 これでword-wrapのないMUAを使うと、大変読みづらいので80桁に到達しないように改行しろというわけだ。 CRLFを含めたのは、多分CRLFにカーソルがいってしまうから左右スクロールするとかそんな感じだろう。

ただ、そもそもの話としてはこれが理由であるが、それを単純に「80桁に制限したほうが見やすい」と思っているのは愚かである。

78文字制限についてはRFC5322に詳しく記載されている。

2.1.1. Line Length Limits

There are two limits that this specification places on the number of characters in a line. Each line of characters MUST be no more than 998 characters, and SHOULD be no more than 78 characters, excluding the CRLF.

The 998 character limit is due to limitations in many implementations that send, receive, or store IMF messages which simply cannot handle more than 998 characters on a line. Receiving implementations would do well to handle an arbitrarily large number of characters in a line for robustness sake. However, there are so many implementations that (in compliance with the transport requirements of [RFC5321]) do not accept messages containing more than 1000 characters including the CR and LF per line, it is important for implementations not to create such messages.

The more conservative 78 character recommendation is to accommodate the many implementations of user interfaces that display these messages which may truncate, or disastrously wrap, the display of more than 78 characters per line, in spite of the fact that such implementations are non-conformant to the intent of this specification (and that of [RFC5321] if they actually cause information to be lost). Again, even though this limitation is put on messages, it is incumbent upon implementations that display messages to handle an arbitrarily large number of characters in a line (certainly at least up to the 998 character limit) for the sake of robustness.

そしてこう書いてある。

2.3. Body

The body of a message is simply lines of US-ASCII characters. The only two limitations on the body are as follows:

o CR and LF MUST only occur together as CRLF; they MUST NOT appear independently in the body. o Lines of characters in the body MUST be limited to 998 characters, and SHOULD be limited to 78 characters, excluding the CRLF.

Note: As was stated earlier, there are other documents, specifically the MIME documents ([RFC2045], [RFC2046], [RFC2049], [RFC4288], [RFC4289]), that extend (and limit) this specification to allow for different sorts of message bodies. Again, these mechanisms are beyond the scope of this document.

そうMIMEエンコーディングによる多言語対応のメッセージボディにはBase64またはuuencodeが使用される。 1行の長さがBase64は76桁、uuencodeは62桁という仕様であり、メッセージデータとしては78桁を越えることはない。

「1行が80桁だから日本語だと40文字」とかいうのは全く意味不明な話である。 そもそも全角の文字が扱えるようになった頃にはそこそこ柔軟なMUAがいくらでもあったし、VT100で日本語表示することはできなかった。 全角の日本語が出せる端末が何桁あるかということはまちまちすぎて統一基準が見いだせないし、世界的に見ればワイド文字という概念がない。 そして、日本語のメールは常にMIMEメッセージとなるため、元々の問題は全く発生しない。 (エンコードされない日本語の書かれたメッセージはe-mailの規格に反している)

さらに、日本語ではword-wrapという概念がなく、「wrapされたら悲惨」という状況にはなりえないため(普通に今も大抵のエディタは禁則処理しないだろう)想定される悪い状況というのが、まぁ、ない。

むしろ変に改行されたほうが、環境によってはものすごく見づらいことになる。

ただ純粋にASCIIだけで編成されるメールを書くときはMIMEエンコードしないMUAはそれなりに存在するため、 その場合は注意を払う必要がある。

sigblock

「デカいsigblockはダサい」というのが風潮であった。 基本的に経験の浅い人ほどsigblockをでかくしたがる、という話である。

--
From James Tiberius Kirk

のように--に続いてsigblockを書く、というルールがあるが、これは慣例的にはUSENETで使われていたものであり、MUAが対応しているという意味も含めて非常に古いものだが、規格化されたのはRFC2646(1999年)でかなり後年になってから。

今も有効なeメールのマナー

  • 自分の名前と相手の名前は本文要約が出るMUAの場合に要約で見えるくらいの位置に書く
  • Fromはなるべく相手が識別しやすい名前を書く
  • 簡潔にまとめる
  • sigblockはちゃんと--行を入れる
  • sigblockはなおさら簡潔に書く