2003-03-01 (土)
■ In-Reply-To は複数の Message-Id を指定できる [電子メール]
In-Reply-To:って複数の Message-Id:を指定できるみたい。知らなかった。[mew-dist 23085]
[RFC2822]
message-id = "Message-ID:" msg-id CRLF
in-reply-to = "In-Reply-To:" 1*msg-id CRLF
references = "References:" 1*msg-id CRLF
<http://www.emaillab.org/essay/index.html>
仮にccヘッダに、A、B、Cという３つのアドレスが書かれている
メールがあった場合、それをメールソフトが「RCPT-To: A」と書いた
メール、そして「RCPT-To: B」、さらに「RCPT-To: C」と書いた３つの
メールに分け、それを順々に１通１通、配送プログラムに渡している。
↓RFC822 に規定されているヘッダは全て説明しているのでいいかも。
<http://www2.luice.or.jp/~deai/backn/master/index.html>
2007-11-16 (金)
■ Message-Id や Date は誰が付けるべきか？ [電子メール]
[2003-03-01-2] のメモにあった URL から抜粋、一部修正。
MTA としての本来の役割を考えてみると、envelope の情報に基づきホストから
ホストへメッセージを配送するのが仕事であり、基本的には(経路情報のヘッダー
を付ける以外)メッセージそのものには関与しない。MTA が Message-ID を付け
るということはヘッダーを解析し、Message-ID がすでにあるかどうか調べると
いうことであり、余計な処理が必要になるということである。つまり、MTA と
しての役割から見た場合、(親切な行為なのか余計なお世話なのかはともかくと
して)必要なこと以上のことを行っているのである。
なお、RFC821(SMTP の仕様書)の改定案の "6.3 Compensating for
Irregularities" では受け取ったメッセージが Message-ID や Date を欠いて
いれば MTA でそれらを追加してよい "MAY" となっている。ただし、そのよう
なメッセージを生成した MUA を "these weak SMTP clients" と呼んでいるこ
とからも、本来は MUA で生成すべきだという考えが読み取れると思う。また、
将来的には欠いているヘッダは Message Submission Agent (MSA) で補完され
るようになるかも知れない(RFC 2476 "Message Submission" を参照)。
(URL: http://www.emaillab.org/essay/message-id.html#where)
2008-02-28 (木)
■ メール本文に ISO-2022-JP を利用することになった背景 [電子メール]
mew-dist 355 (古い...) から一部抜粋。
仕様では通常、シンタックスとセマンティクスを定義します。
RFC822 では、ヘッダのセマンティクスもボディのセマンティクスも ASCII と
定めています。ASCII とは、0-127 の範囲を ASCII 表にある文字として解釈
するというセマンティクスです。ただ、RFC822 の執筆当時 Dave が気が付い
ていた犯しやすいシンタックス上の問題点(単一の CR など)は明確に排除しま
した。
日本で本文に ISO-2022-JP を入れたのは、シンタックス上は問題ありません
が、セマンティクスを破っています。ASCII 文字列中に ESC シーケンスが現
れても、それは単なる ESC シーケンスですから、日本語として取り扱われま
せん。また、ヨーロッパでは、本文に 0-255 までを許し、これを Latin-1 と
解釈することにしました。これはシンタックスもセマンティックスも破ってい
ます。しかし、所詮、日本で ISO-2022-JP を利用しようとした背景は、ヨー
ロッパが 8bit 領域を使っていたからにほかなりません。日本でも EUC Japan
を標準に選ぶ可能性はあったということです。
シンタックスは「構文」、セマンティクスは「データの意味」のことらしい。へぇ〜。
Gartner Column：第11回 そもそも「セマンティクス」とは何だろう？が参考になるかも。
追記20090405:
関連する話題があったので、貼り付けておきますね。
(URL: 日本語のe-mail、ISO-2022-JP以外のcharsetを使うのは是か非か - スラッシュドット・ジャパン)
個人的には ISO-2022-JP で表現できない内容なら、Unicode で送るのはまっ
たく問題ないと思います。ただ上の記事にあるように、本文に 8bit 目を
使うのはシンタックスを破ることになるので、base64 符号化は必須です。
Shift-JIS や EUC-JP を base64 符号化せずに送るのは 8bit 目を使って
いるので論外ですが、じゃあ Shift-JIS+base64 や EUC-JP+base64 なら良
いの？と言われるとこれも NO です。ISO-2022-JP で送れば素直なプレー
ンテキストになるのに、無駄な符号化をしているので。
2009-03-14 (土)
■ 電子メールでの一行の制限 [電子メール][Mew]
SMTP プロトコルが定義された RFC 5321 によると、"4.5.3.1.6. Text
Line" に一行は(英文字で) 1000 文字までと制限されている。
原文
The maximum total length of a text line including the <CRLF> is 1000
octets (not counting the leading dot duplicated for transparency).
This number may be increased by the use of SMTP Service Extensions.
日本語訳
<CRLF> を含むテキスト行の最大長は 1000 オクテットです(透過性のために
付けられた複製した先頭のドットはカウントしません)。この数値は SMTP
サービス拡張の使用によって増加するかもしれません。
(URL: http://www.hde.co.jp/rfc/rfc5321.php)
実際はユーザが意識する必要はなくて、MUA(メーラ) が適切に処理してく
れる。例えば Mew は長い行があるとエンコード方法を訊いてくる。
Lines are too long. Input encoding (base64):
ではメーラが適切に処理しなければどうなるのか？ MTA(転送プログラム)
が適切に処理してくれる。例えば sendmail の標準的な設定では、990 文
字目に !<cr><lf> が挿入される。
もっとも、メーラは RFC 5321 を意識しているわけではなく、RFC 2822(電
子メールの仕様) に則って実装されている。"2.1.1. Line Length
Limits" によると、1 行は(英文字で) 78 文字以下であるべきで、998 文
字以下でなければならないと定められている。
原文
There are two limits that this standard 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.
日本語訳
この標準では１行中の文字数に２つの制限がある。それぞれの行の文字はCRLF
を除いて、決して998文字以下でなければならず(MUST)、78文字以下であるべ
きである(SHOULD)。
(URL: http://www.puni.net/~mimori/rfc/rfc2822.txt)
一方、RFC 3676 で Text/Plain が拡張され、送信元のメーラが対応してい
ればユーザは長い行を気軽に書いてもよくなった。そのようなメールのヘッ
ダ部分には "Text/Plain" のパラメータとして "format=flowed" が設定さ
れ、長い行の途中には適度に「半角スペース+改行」が挿入される。これに
より連続した行が折り返されたものか、本当に改行されたものかが分かる。
そのため、受信者側のメーラは適度に改行して表示できるようになった。
Content-Type: Text/Plain; charset=us-ascii; format=flowed
上記は英語本文の場合だが日本語本文の場合、以下のような値となる。
Content-Type: Text/Plain; charset=iso-2022-jp; format=flowed; delsp=yes
"delsp=yes" とは何か？英語本文は単語の途中で折り返されることはない
ため、折り返された行を連結したい時は行末のスペースをそのまま単語の
区切りに使えばよい。しかし、日本語本文でそれをやると単語の途中で半
角スペースが現れ、みすぼらしい文章になる。よって、連結する時は行末
の半角スペースを削除してねというお願いが "delsp=yes" というわけ。
Mew のデフォルトでは "format=flowed" は OFF だが、以下の 2 種類の方
法で ON にすることが出来る。
送信メールは常に "format=flowed" を ON にする。
(setq mew-use-format-flowed t)
現在作成しているメールの "format=flowed" を ON にする。
draft-mode で C-c C-f
Mew は "format=flowed" でないメールは、何も加工せずに表示する。
Summary-mode で `_' することによって、折り返された行、長い行、通常
の行の順に行の表示を変えることが出来る。
それに対して、"format=flowed" なメールは一度 `_' された状態で表示される。
※ Mew での長い行の扱いについては、Info の longline の項に記載されている。
2009-05-16 (土)
■ telnet で直接 web サーバとお話しする。 [Apache][電子メール]
[2004-02-09-1] の HTTP 版です。
Web ブラウザは HTTP リクエストを送信し、返ってきたステータスコード
や、生の HTML 等を解析するのが仕事です。
HTTP リクエストは簡単なので、人間が telnet で接続しサーバとお話しす
ることもできます。
▼存在するページを指定すると、200 ステータスコードとともに、生の
HTML コードが出力されます。
% telnet www.example.com 80 Trying 208.77.188.166... Connected to example.com. Escape character is '^]'. GET /index.html HTTP/1.0 #<= 入力後、Enter×2回 HTTP/1.1 200 OK #<= ステータスコード 200 が返ってきた。 (以下省略)
▼存在しないページを指定すると、404 ステータスコードが出力されます。
% telnet www.example.com 80 Trying 208.77.188.166... Connected to www.example.com. Escape character is '^]'. GET /hoge.html HTTP/1.0 #<= 存在しないページを入力後、Enter×2回 HTTP/1.1 404 Not Found #<= ステータスコード 404 が返ってきた。 (以下省略)
▼オプション(HTTP ヘッダ)を指定すると、環境変数として CGI に渡ります。
この例だと分かりませんが、簡単な CGI のプログラムで確認出来ます。
% telnet www.example.com 80 Trying 208.77.188.166... Connected to example.com. Escape character is '^]'. GET /index.html HTTP/1.0 #<= 入力後、Enter×1回 User-Agent: Telnet [ja] (Linux) #<= 適当な User-Agent を入力後、Enter×2回 HTTP/1.1 200 OK #<= ステータスコード 200 が返ってきた。 (以下省略)
▼まとめ
200: OK -> 正常にアクセスできた。
404: Not Found -> ページが見つからなかった。
参考情報: Wikipedia - Http
参考情報: Wikipedia - HTTPステータスコード
参考情報: telnetでブラウズ(HTTP)
こうして確認してみると、HTTP のデータ構造は電子メール(RFC2822)とそっ
くりだということが分かります。両方ともヘッダは複数の
フィールド名: 内容
で構成され、最後は空行で終わります。
あと、[2003-06-08-1] にも書きましたが、例で使っている example.com
は、予約ドメインとして RFC2606 に定義されています。実際にアクセスす
ることも出来ます。
最終更新時間: 2010-07-27 06:00
