Gmail이 인라인 첨부 파일에 대해 유효하지 않은 Content-ID 헤더를 설정 했습니까?

Question

짧은 버전

첨부 파일의 Content-ID 헤더는 local-part "@" domain 형식이어야합니다. Gmail의 콘텐츠 ID에는 @이 없습니다. 이것이 진짜 버그입니까, 아니면 사양을 잘못 읽고 있습니까? 내가 첨부 된 인라인 이미지가 Gmail에 보낸 이메일을 다시 보내하려고 할 때

롱 버전

나는이 문제를 발견했습니다. 저의 메일러 (SwiftMailer)는 Content-ID가 유효하지 않다고 주장했습니다.

Here's the email I'm working with. Gmail에서 이미지를 인라인으로 삽입하고 이메일로 보내면됩니다. 여기

는 (지금까지 내가 말할 수있는) 사양의 관련 부분은 다음과 같습니다

RFC 2045

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 here 및 here

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

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

내가 여기서 무엇을 놓치고 ? Gmail이 사양을 따르지 않습니까, 아니면 콘텐츠 ID에 @이 없어도 괜찮습니까? 아무도로 보는

Answer 1

이 더 나은 대답을 게시 ... RFC에의

내 해석은 당신과 함께 맞습니다. 나는이 책에서 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--