107.txt

[2] [CODE[Received:]] 欄は、普通[[電子メイル]]で使って、配送の記録が行われる欄です。
他に、電子ニュースでもかつてはつかわれていました。

* 仕様書

[REFS[
- [36] [CITE@en[RFC 5321 - Simple Mail Transfer Protocol]] ([TIME[2016-01-10 14:43:30 +09:00]] 版) <https://tools.ietf.org/html/rfc5321#section-4.4>
]REFS]

* 電子メイルにおける Received: 欄

[3] 配送の各段階の数だけどんどん追加されていきます。
メイルがどのような経路で配送されたのかやどのサーバーが不調なのかなどの追跡に使用出来ます。
(現在では途中経路を数 hop も経ないで直接サイトからサイトに配送されるのが普通ですし、途中の経過サイトの不調のための遅延もかなり稀ですが、昔はよくあることでした。)

- [[.//RFC822]] (822 旧仕様)
- [[.//RFC2822]] (822)
- [[.//RFC821]] (SMTP 旧仕様)
- [[.//RFC2821]] (SMTP)

[5] [[RFC2822]] は一般的な [CODE[Received:]] 欄の構文を規定しています。
[[RFC2821]] ([[SMTP]]) は、 SMTP サーバーが [CODE[Received:]]
欄に記録すること及びその書式を規定しています。 RFC 2821 の構文は
RFC 2822 のものより具体的・厳格になっています。

RFC 2822, RFC 2821 の旧版である [[RFC822]], [[RFC821]]
についても同じような関係がありますが、 2822/2821 程はっきり分化してはいません。

[[#comment]]


** 値

- by = domain
- for = addr-spec / "<" [route] addr-spec ">"
- from = domain
- id = word / msg-id
- via = "TCP" (2821) / "UUCP" (2821) / iana-atom 
/ "smtptcp" / "TELNET" (821) / "DDN" / "ARPANET/MILNET" / "EUnet"
- with = "ESMTP" (2821) / "SMTP" (2821) / iana-atom 
/ "X25" (821) / "TCP/SMTP" / "Mailnet" / "BSMTP"

昔は結構すきなよーな値を入れてたらしい。

"BSMTP" [[BITNET]] 版 [[SMTP]]?

- [11] [[RFC1428]] は値 [CODE[convert]] を規定しています。 "rfc822-to-8bit", "rfc822-to-base-64" or "rfc822-to-quoted-printable"

[14]
[SAMP(822)[with QMQP]]: [[QMQP]] — Quick Mail Queueing Protocol [djb]
ってのもしばしば使われている模様。
([[名無しさん]] [WEAK[2004-07-11 01:06:33 +00:00]])

[15]
[CODE(822)[from unknown]] ってのも昔からよく見かけます。
([[名無しさん]])

[16]
[SAMP(822)[with internal]] なるものも使われています。
([[名無しさん]] [WEAK[2004-07-11 01:08:13 +00:00]])

[37] [CODE[SMTP]] と [CODE[ESMTP]] の値の意味は [[RFC 5321]]
には明記されていません。いつどちらを使うべきかは明らかではありません。

[17]
[SAMP(822)[via csmap]]
([[名無しさん]] [WEAK[2004-07-11 01:10:29 +00:00]])

[38] [CODE[VIA]] は省略されることが多いようです。 [CODE[VIA TCP WITH SMTP]]
と書いてもほとんど意味が無いからでしょう。

[18]
こういうとんでもなのもあった: [SAMP(822)[with Microsoft SMTPSVC(5.0.2195.6824)]]
([[名無しさん]] [WEAK[2004-07-11 01:26:00 +00:00]])

[19]
[CODE(822)[WITH]] の値に6月に色々追加されています。典拠は RFC-to-be です。

追加されたのは
[CODE(822)[ESMTPA]], [CODE(822)[ESMTPS]], [CODE(822)[ESMTPSA]], [CODE(822)[LMTP]], [CODE(822)[LMTPA]], [CODE(822)[LMTPS]], [CODE(822)[LMTPSA]], [CODE(822)[ESMTP]] です。 [CODE[A]] は [[SMTP AUTH]], [CODE[S]] は [[TLS]], [CODE[LMTP]] は [[LMTP]] です。 [CODE(822)[ESMTP]] は [Q[ESMTP with NO-SOLICITING]] と書いてありますが、既に [Q[SMTP with Service Extensions       [RFC2821] ]] が登録されているので、何かの間違いでしょう。

([[名無しさん]] [WEAK[2004-07-11 02:39:26 +00:00]])

[20]
''MAIL Parameters'' <http://www.iana.org/assignments/mail-parameters>
([[名無しさん]] [WEAK[2004-07-11 02:39:56 +00:00]])

[21]
[SAMP(822)[with ESMTP/inet]] こんなのもある。
([[名無しさん]] [WEAK[2004-07-11 02:42:34 +00:00]])

[22]
[SAMP(822)[by [VAR[foo.example.org]] (AppleMailServer 38.0.2.6) id 668620 via NDR]]

こんなのがあった。
([[名無しさん]] [WEAK[2004-07-11 02:55:55 +00:00]])

[23]
[CODE(822)@en[[[WITH]]]] として [CODE(822)@en[[[MMS]]]]
が登録されました。
([[名無しさん]] [WEAK[2006-08-12 07:33:09 +00:00]])

[24]
太古の昔の: [CODE(822)@en[[[WITH]] [[TCP]]]]
([[名無しさん]])

[25]
[[Gmail]]: [CODE(822)@en[[[with]] [[HTTP]]]]

[31] [CODE(822)@en[[[with]] [[POP3]]]]

[29] [[IANA]] 登録簿に [[draft-ietf-eai-rfc5336bis-16]] を出典として
[CODE(822)@en[[[UTF8SMTP]]]], [CODE(822)@en[[[UTF8SMTPA]]]], 
[CODE(822)@en[[[UTF8SMTPS]]]], [CODE(822)@en[[[UTF8SMTPSA]]]],
[CODE(822)@en[[[UTF8LMTP]]]], [CODE(822)@en[[[UTF8LMTPA]]]], 
[CODE(822)@en[[[UTF8LMTPS]]]], [CODE(822)@en[[[UTF8LMTPSA]]]]
が追加されています。 [TIME[2011-12-10T11:03:15.00Z]]

** 注釈 comment について

RFC 2821 は慣習的に行われてきた、 comment 内に実ドメイン名・ IP address を
記録する方法を標準化しました。これに限らず Received: 領域の
注釈には有意義な情報が入れられていますから、注釈を取り除いて
解釈するのはよくないかもしれません。

しかし注釈は (RFC 2821/2822 で入る場所が限定されたとはいえ) RFC 822 以来
各要素間どこにでも入れられるので、構文解析 parse が面倒になります。
また、 RFC 2821 で標準化された注釈とそうでない注釈を
一目で見分ける方法はありません。

ですから、 Received: を解釈する実装としては、次のようなものが考えられます。

- 非構造化 unstructured 領域と同等に見て、構文解析しない
- 注釈内の情報を残すのは諦め、取り除いて解析する
- RFC 2821/2822 的に妥当 (で旧構文 obsolete syntax でない) 注釈はなんとか解析する
- 注釈は解析しないが、参考情報として残す

3番目の方法は旧構文の注釈 (例えば date-time 内の注釈) は取り除く必要が
あるので、なんだか面倒そうです。それから4番目の方法は
そこまでするならあと1歩で中身も解析出来る気が。

わけのわからんことぐたぐた述べてないで実装してみた方が
早いという説もありますが:-)

[6] [[MIME]] は [CODE[encoded-word]] を規定していますが、これを [CODE[Received:]]
欄の注釈内で使用してもいいのかは不明です。 (See [[encoded-word]>>12])

[7] [CODE[Received:]] 欄の日付の部分の後 (つまり一番最後)
には、その欄を加えたサーバーの現地の[[時間帯を表す文字列]]を注釈として入れておくと追跡の時に役に立つかもしれないのでイイとされています。

[[#comment]]


** env-from

- Received = rfc2822.Received FWS "env-from" FWS "(" host ")" [CFWS]

こんなのをつけてくる [[MTA]] がいるみたい。
例:

[PRE[
 Received: from localhost (daemon@localhost)
	by smtp.foo.example (8.9.3/8.9.3) with SMTP id KAA25477;
	Fri, 23 Feb 2001 10:42:36 +0900 (JST)
	env-from (from@bar.example)
]PRE]

[[#comment]]


** 参考

Received: 領域の数が多いと配送拒否されることがあるので、
mail-list などで Received: を X-Received: に置き換えることがある。
(あるいはそこでばっさり消されることもある。)

[9] [CODE[Received:]] 欄は長くなりがちなので、たいてい折畳まれています。
この時、2行目以降の行頭は [CODE(CHARNAME)[TAB]] になっているのが普通です。
また、名前‐値組の間や日付の途中で折畳むことはありません。

しかし、これはそうなっていることが多いだけで、 RFC 2822 や RFC 2821
を読んでもこれが強制されてはいないことが分かります。

[[#comment]]


** 関連する IANA 登録簿

- Mail parameters <http://www.iana.org/assignments/mail-parameters>
[[#comment]]


** 例

- [10] 以下の例は規格への適合性により分類していますが、この判断にはちょっと疑問もあります。
構文や本文規定を参考に振り分けなおす必要があるかもしれません。
[[#comment]]


*** RFC 2821 的に適当なもの

- Received: from foo3.example (foo4.example [127.0.0.1]) by foo2.example (Postfix) with ESMTP id E7F0824030; Sat, 16 Mar 2002 21:40:39 +0900 (JST)
- Received: (qmail 16842 invoked from network); 16 Mar 2002 21:41:54 +0900
- Received: (qmail 12928 invoked by uid 38); 16 Mar 2002 13:01:43 -0000
- Received: from foo8.example (mail@192.168.0.11) by foo9.example with SMTP; 16 Mar 2002 13:01:40 -0000
- Received: (from uucp@localhost) by foo9.example (8.9.1a/3.7W-u48) id OAA09787; Tue, 12 Mar 2002 14:12:37 +0900 (JST)
- Received: by foo10.example (8.9.1a/3.7W-hack) id OAA03107 for hoge-outgoing; Tue, 12 Mar 2002 14:08:04 +0900 (JST)
- Received: from foo.bar2.example ([61.198.253.195]) by foo.bar3.example (8.9.3 (PHNE_24848+JAGad82359)/8.8.6) with ESMTP id JAA17845; Sat, 9 Mar 2002 09:30:50 +0900 (JST)

[[#comment]]


*** RFC 2821 的に不適当だが RFC 2822 的に適当なもの

- Received: from unknown (HELO foo1.example) (192.168.0.1) by foo2.example with SMTP; 16 Mar 2002 21:41:54 +0900
- Received: from foo4.example (unknown [192.168.0.8]) by foo5.example (Postfix) with ESMTP id 48DB815007 for <bar@foo5.example>; Sat, 16 Mar 2002 21:04:21 +0800 (CST)
- Received: from bar by foo8.example with local (Exim 3.12 1 (Debian)) id 16mDoa-0004ep-00; Sat, 16 Mar 2002 07:01:40 -0600
- Received: from localhost ([127.0.0.1] helo=foo.bar1.example) by bar.bar1.example with esmtp (Exim 3.31-VA-mm2 #1 (Debian)) id 16jUlY-0006UE-00; Fri, 08 Mar 2002 16:31:16 -0800


*** その他

- Received: from foo6.example [192.168.0.10] by foo7.example with smtp (Exim 3.12 1 (Debian)) id 16mDoZ-0004ec-00; Sat, 16 Mar 2002 07:01:39 -0600
- Received: from mailhost(192.9.200.18) by hogehoge via smap/slg/sizecheck/clearerr (V1.3) with ESMTP id fmala9603; Tue Mar 12 14:11:44 2002

[[#comment]]


** 参考文献

- [1] ''Fight spam on the Net!'' <http://ssss.jp/~trombik/email/index.html>
[CODE[Received:]] 欄の読み方を学習するのにいいでしょう。
[[#comment]]


** メモ

- [12] たまに、特に [[ML]] なんかで、おせっかいにも送信者にお宅の時計ずれてませんか? とか忠告する人いますね。 [CODE(822)[[[Date:]]]] 欄の日付が受信時刻からあまりに離れているからとか、 ML の他のメイルと番号と日付の関係が合わなかったりするのを根拠にそう言うんでしょうが。実際よく見てみると送信者の方の時計はおそらくあっていて、転送路の問題で遅れただけであることも実はよくあったりします。[WEAK[ML server が遅延の原因だったりすることもあったりします。]] わざわわざわざ忠告してみて知識をひけらかす暇があったら、 [CODE(822)[Received:]] 欄の読み方くらい勉強した方がいいですね(w
- [13] ほんとに、メイルが届くのに時間がかかって、しかも届くかどうか分からなかった時代は遠くに行ってしまったんですねぇ。それでも未だに遅延があるからには [CODE(822)[Received:]] 欄の存在意義も減らないとは思うんですけど、メイル配送路障害のことなんて考えもしない人が増えてるんだろうなあ。
[[#comment]]


* 電子ニュースにおける Received: 欄

[3] かつて Received: は記事を受け取った時間を表す領域として
USENET で使われていた。領域本体の値は USENET 形式の日付。
(See [[日付形式]]) RFC 850 ではすでに旧式とされ [[Date-Received:領域]] を使う
ことになっているが、 RFC 850 および RFC 1036 の例に挙がっている。

[4] 今ではもう使用されることはないでしょう。ただ、 [[INN]]
は現在の版でも [CODE[Received:]] 欄を持つメッセージの投稿は拒否します。
([CODE[Received:]] 欄のあるメッセージを中継する時は中継元で落としてから中継先に送っていた。)

[[#comment]]


* メモ

[26]
[[RFC 5335]] は、 [CODE(822)@en[[[For]]]] [[欄]]における [[UTF-8]]
を含む[[電子メイル番地]] ([CODE(ABNF)@en[[[utf8-addr-spec]]]]) の使用を認めています。
[[RFC 5335]] はこれを [[uFor]] 構文と呼んでいます。

;; [[RFC 5335]] 4.5

[28] [CITE[FGA: Some of what is said about "qmail" is wrong]] ([TIME[2004-12-08 10:45:51 +09:00]] 版) <http://homepages.tesco.net/J.deBoynePollard/FGA/qmail-myths-dispelled.html#MythAboutQQReceivedHeaders>

[27] [CITE@ja[qmailのReceivedヘッダがRFC違反に? « 雑多なブログ]] ([TIME[2008-12-29 20:46:17 +09:00]] 版) <http://tec.jpn.ph/wordpress/?p=883>





[30] [CITE@en[RFC 6729 - Indicating Email Handling States in Trace Fields]]
( ([TIME[2012-09-08 08:24:48 +09:00]] 版))
<http://tools.ietf.org/html/rfc6729>

[32] 
[PRE(822 example code)[
Received: from 291235132082.apps.googleusercontent.com
	named unknown
	by gmailapi.google.com
	with HTTPREST;
	Thu, 24 Jul 2014 20:14:57 -0700
]PRE]

;; [[Gmail API]] から送信したメール

[8] 
[PRE(822 code)[
Received: by filter-171.sjc1.sendgrid.net with SMTP id filter-171.16166.544FBEEA19
        2014-10-28 16:06:04.814281002 +0000 UTC
]PRE]


[33] [CITE@ja[Received: format of various SMTP Mail Transfer Agents]]
( ([TIME[2012-01-30 18:26:40 +09:00]] 版))
<http://vega.sra-tohoku.co.jp/~kabe/vsd/mail/received.html>

[FIG(quote)[
[FIGCAPTION[
[34] [CITE@en[RFC 1428 - Transition of Internet Mail from Just-Send-8 to 8bit-SMTP/MIME]]
([TIME[2015-07-26 14:25:37 +09:00]] 版)
<https://tools.ietf.org/html/rfc1428>
]FIGCAPTION]

> 
>    Trace information should be added to the document with a convert
>    clause: "rfc822-to-8bit", "rfc822-to-base-64" or "rfc822-to-quoted-
>    printable" e.g.,
>    Received: from dbc.mtview.ca.us by dbc.mtview.ca.us
>              convert rfc822-to-8bit; Tue, 01 Sep 1992 01:18:00 -0700

]FIG]


[FIG(quote)[
[FIGCAPTION[
[35] [CITE@en[old-delphi-codes/headers.txt at master · maerlyn/old-delphi-codes]]
([TIME[2016-01-15 19:33:13 +09:00]] 版)
<https://github.com/maerlyn/old-delphi-codes/blob/master/POPper/GUI%20no2/headers.txt>
]FIGCAPTION]

> 
> Received: from dial-3-236.emitel.hu(194.149.57.236) by brutus via csmap (V6.0)
> 	id srcAAAb2aGGy; Tue, 6 Apr 04 17:55:45 +0200

]FIG]