Received:

Received: ヘッダー (インターネットメール)

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

仕様書

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

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

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

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

  • 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" BITNETSMTP?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[25] Gmail: with HTTP

[31] with POP3

[29] IANA 登録簿に draft-ietf-eai-rfc5336bis-16 を出典として UTF8SMTP, UTF8SMTPA, UTF8SMTPS, UTF8SMTPSA, UTF8LMTP, UTF8LMTPA, UTF8LMTPS, UTF8LMTPSA が追加されています。

注釈 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] MIMEencoded-word を規定していますが、これを Received: 欄の注釈内で使用してもいいのかは不明です。 (See encoded-word (>>12))

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

env-from

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

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

 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)

参考

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

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

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

関連する IANA 登録簿

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

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)

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

参考文献

メモ

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

歴史

USENET ニュースメッセージ

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

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

RFC 2822

[39] RFC 2822 3.6.7. Trace fields 追跡欄

The trace fields are a group of header fields consisting of an optional "Return-Path:" field, and one or more "Received:" fields. The "Return-Path:" header field contains a pair of angle brackets that enclose an optional addr-spec. The "Received:" field contains a (possibly empty) list of name/value pairs followed by a semicolon and a date-time specification. The first item of the name/value pair is defined by item-name, and the second item is either an addr-spec, an atom, a domain, or a msg-id. Further restrictions may be applied to the syntax of the trace fields by standards that provide for their use, such as [RFC2821].

追跡欄は省略可能な "Return-Path:" 欄と1つ以上の "Received:" 欄からなる頭欄の集団です。 "Return-Path:" 頭欄は angle 括弧の組とそれに囲まれた省略可能な addr-spec で構成されます。 "Received:" 欄は (空かも知れない) 名前/値の組の表にセミコロンと date-time 記述が続くものです。名前/値組の最初の項目は item-name で定義され、2番目の項目は addr-spec, atom, domain, または msg-id で定義されます。追跡欄の構文はこれを使う RFC 2821 のような規格により更なる制限が加えられるかもしれません。

  • trace = [return] 1*received
  • return = "Return-Path:" path CRLF
  • path = ([CFWS] "<" ([CFWS] / addr-spec) ">" [CFWS]) / obs-path
  • received = "Received:" name-val-list ";" date-time CRLF
  • name-val-list = [CFWS] [name-val-pair *(CFWS name-val-pair)]
  • name-val-pair = item-name CFWS item-value
  • item-name = ALPHA *(["-"] (ALPHA / DIGIT))
  • item-value = addr-spec / atom / domain / msg-id

A full discussion of the Internet mail use of trace fields is contained in [RFC2821]. For the purposes of this standard, the trace fields are strictly informational, and any formal interpretation of them is outside of the scope of this document.

追跡欄の Internet メイルでの仕様についての完全な議論は RFC 2821 に含まれています。この規格の目的では、追跡情報は完全に情報提供的なもので、これらの正式な解釈はこの文書の適用範囲外とします。

[40] RFC 2822 4.5.7. Obsolete trace fields

The obs-return and obs-received are again given here as template definitions, just as return and received are in section 3. Their full syntax is given in [RFC2821].

  • obs-return = "Return-Path" *WSP ":" path CRLF
  • obs-received = "Received" *WSP ":" name-val-list CRLF
  • obs-path = obs-route-addr

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

[28] FGA: Some of what is said about "qmail" is wrong ( 版) <http://homepages.tesco.net/J.deBoynePollard/FGA/qmail-myths-dispelled.html#MythAboutQQReceivedHeaders>

[27] qmailのReceivedヘッダがRFC違反に? « 雑多なブログ ( 版) <http://tec.jpn.ph/wordpress/?p=883>

[30] RFC 6729 - Indicating Email Handling States in Trace Fields ( ( 版)) <http://tools.ietf.org/html/rfc6729>

[32]

Received: from 291235132082.apps.googleusercontent.com
	named unknown
	by gmailapi.google.com
	with HTTPREST;
	Thu, 24 Jul 2014 20:14:57 -0700

Gmail API から送信したメール

[8]

Received: by filter-171.sjc1.sendgrid.net with SMTP id filter-171.16166.544FBEEA19
        2014-10-28 16:06:04.814281002 +0000 UTC

[33] Received: format of various SMTP Mail Transfer Agents ( ( 版)) <http://vega.sra-tohoku.co.jp/~kabe/vsd/mail/received.html>

[34] RFC 1428 - Transition of Internet Mail from Just-Send-8 to 8bit-SMTP/MIME ( 版) <https://tools.ietf.org/html/rfc1428>

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

[35] old-delphi-codes/headers.txt at master · maerlyn/old-delphi-codes ( 版) <https://github.com/maerlyn/old-delphi-codes/blob/master/POPper/GUI%20no2/headers.txt>

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