質問: 現在独自ドメインでメールが利用できるように設定しています。 とりあえずうまくいったのですが、1つわからないことがあるので、教えていただけると幸いです。 メールヘッダを見ると以下の様な値があります。 ``` Received: from example.net (example.com [xxx.xxx.xxx.xxx]) (後略) ``` このうち「example.net」と「example.com」という値はどこから取得しているのでしょうか。 前者については、サーバーに設定しているホスト名だと思いますが、後者の値が何を表しているのかわからずにいます。 もし「example.com」の部分を変更できるのであれば、どのように変更すればよいのでしょうか。 環境はUbuntu18.04、メールサーバーはDovecotです。 以上、よろしくお願いいたします。
回答: たぶん、この仕様に基づいて記録されています。 RFC 5321(Simple Mail Transfer Protocol) > > **4.4. トレース情報** > > SMTP サーバーが配送またはさらなる処理のためにメッセージを受信したとき、セクション 4.1.1.4 で議論されている通り、メッセージ内容の先頭にトレース("タイムスタンプ(time stamp)" または "Received")情報を追加しなければならない(MUST)。 > > > この行は以下のように構造化されなければならない(MUST): > > > * SMTP 環境では必ず提供されなければならない(MUST) FROM 節は、(1) EHLO コマンド内で提示される通りの送信元ホスト名と、(2) TCP 接続から決定される送信元の IP アドレスを含むアドレスリテラルとを、両方含むべきである(SHOULD)。 > * ID 節は RFC 822 で提案されている "@" を含んでもよい(MAY)が、必須ではない。 > * FOR 節が現れる場合、たとえ複数の RCPT コマンドが与えられたとしても、正確にひとつの エントリを含まなければならない(MUST)。複数の はある種のセキュリティ問題を引き起こすため、非推奨である。セクション 7.2 参照。 > > > インターネットメールプログラムは、メッセージのヘッダセクションにすでに追加されている Received: 行を変更したり削除したりしてはならない(MUST NOT)。SMTP サーバーはメッセージの先頭に Received 行を追加しなければならない(MUST)。既存の行の順序を変更したり、別の位置に Received 行を挿入したりしてはならない(MUST NOT)。 > > > おそらく、「example.net」の部分は、「(1) EHLO コマンド内で提示される通りの送信元ホスト名」、**「example.com」の部分は、「(2) TCP 接続から決定される送信元の IP アドレスを含むアドレスリテラル」に該当すると思われます。** 同文書の前後に以下のようにあるので、「Dovecot」で **「自身の "Received:" フィールド」については内容「example.com」を変更することは出来なくはないでしょうが、やらない方が良いでしょう。** > > **3.6.3. リレーとしてのメッセージサブミッションサーバー** > > > 途中省略 > > > セクション 6.4 の議論の通り、リレー SMTP はメッセージのヘッダ部やボディを検査したり、それらに基づいて動作したりする必要はなく、**またヘッダに自身の "Received:" フィールド(セクション 4.4)を追加する場合と、オプションでメールシステム内のループの検出を試みる場合とを除き、そうしてはならない(MUST NOT)。** 当然ながらこの禁止事項は、これらのヘッダフィールドまたはテキストに対する変更にも適用される(セクション 7.9 も参照してほしい)。 > > > **3.7.2. ゲートウェイにおける Received 行** > > メッセージをインターネット環境の内側または外側へ転送するとき、ゲートウェイは Received: 行を追加しなければならない(MUST)が、すでにヘッダセクションに追加されている Received: 行を変更してはならない(MUST NOT)。 > > > 他の環境から発信されたメッセージの "Received:" フィールドは、本仕様に正確に従わない可能性がある。**しかしながら、Received: 行のもっとも重要な使用法はメール障害のデバッグ作業であり、Received: 行を "修正(fix)" しようとする善意のゲートウェイによって、そのデバッグ作業はひどく妨げられる可能性がある。** 非 SMTP 環境で発生したトレースヘッダフィールドのための別の結論として、受信システムはトレースヘッダフィールドのフォーマットに基づいてメールを拒否してはならず(MUST NOT)、予期せぬ情報やそれらのヘッダフィールドのフォーマットを踏まえて、極めて頑強であるべきである(SHOULD)。 > > > **6.4. 不正行為を補正する** > > > 内容抜粋(全文は紹介先を参照のこと) > > > 発信 SMTP サーバー、または初期投入(メッセージサブミッション)プロトコルとしての SMTP の接続先として使用される SMTP サーバーが必要とするのであれば、処理されるメッセージに以下の変更が適用されてもよい(MAY): > > > * アドレスを適切な FQDN フォーマットに修正する > > > 修正を行うべきかどうかやその方法を考慮するとき、クライアントに付いてサーバーが持つ情報が少なければ少ないほど、これらの変更は正しくなりそうになく、より警戒と保守主義とが適用されるべきである。これらの変更は中間リレー機能を提供する SMTP サーバーによって適用されてはならない(MUST NOT)。 > > > 関連記事: メールヘッダの Received フィールドの読み方 ▼各種メールサーバーのReceived: 形式▼