9

短縮版

添付ファイルの Content-ID ヘッダーは、 の形式である必要がありますlocal-part "@" domain。Gmail の Content-ID には がありません@これは本当のバグですか、それとも仕様を読み違えていますか?

ロングバージョン

インライン画像が添付された Gmail から送信されたメールを再送信しようとしたときに、この問題に気付きました。私のメーラー (SwiftMailer) は、Content-ID が無効であると主張しました。

これが私が使用している電子メールです。これは、Gmail に画像をインラインで挿入し、自分宛にメールで送信することで作成しました。

仕様の関連部分は次のとおりです(私が知る限り):

RFC2045

Content-ID Header Field

In constructing a high-level user agent, it may be desirable to allow
one body to make reference to another.  Accordingly, bodies may be
labelled using the "Content-ID" header field, which is syntactically
identical to the "Message-ID" header field:

 id := "Content-ID" ":" msg-id

RFC 822ここここ

msg-id      =  "<" addr-spec ">"            ; Unique message id

addr-spec   =  local-part "@" domain        ; global address

ここで何が欠けていますか?Gmail は仕様に従っていませんか、それとも@Content-ID に がなくても問題ありませんか?

4

1 に答える 1

10

誰もより良い回答を投稿していないのを見て…</p>

RFC の私の解釈は、あなたの解釈と一致します。ここでは、Gmail が間違ったことをしていると言えます。ただし、Gmail が行うことは、定義上事実上有効です。Gmail はあまりにも人気があり、他のソフトウェアが受け入れないわけではありませんが、Gmail は、標準的な慣行になるまで、より多くのソフトウェアが同じように仕様に違反する可能性があります。

残念ながら、これは現在、現実に一致する正確な仕様がないことを意味します. 幸いなことに、この質問は現在 Google の検索結果に表示されています。


質問の元のメールはなくなっているので、別の例を次に示します。これは、マルチパート メッセージのエンコードされたイメージ部分です。Content-ID ヘッダーに注意してください。

--089e0153807e5a346d04f1ae7c38
Content-Type: image/gif; name="blank.gif"
Content-Transfer-Encoding: base64
Content-ID: <ii_14403b4fa16783bf>
X-Attachment-Id: ii_14403b4fa16783bf

R0lGODlhAQABAIAAAP///wAAACH5BAEAAAAALAAAAAABAAEAAAICRAEAOw==
--089e0153807e5a346d04f1ae7c38--
于 2014-02-05T21:49:14.593 に答える