이메일 MIME에 Content-ID 헤더가 있으면 첨부 파일을 포함해야합니까?


11

우리가 가지고있는 두 개의 다른 타사 전자 메일 제품 은 전자 메일의 MIME 소스에 content-id 헤더가있는 것과 다르게 반응 합니다. 이로 인해 해결하려는 사용자 환경이 일관되지 않습니다.

예를 들면 다음과 같습니다.

--boundary-example
Content-Location: CID:somethingatelse 
Content-ID: <foo4atfoo1atbar.net>
Content-Type: IMAGE/GIF
Content-Transfer-Encoding: BASE64

R0lGODlhGAGgAPEAAP/////ZRaCgoAAAACH+PUNv
cHlyaWdodCAoQykgMTk5LiBVbmF1dGhvcml6ZWQgZHV
wbGljYXRpb24gcHJvaGliaXRlZC4A etc..

한 이메일 제품이이를 임베디드 이미지로 해석합니다. 다른 사람은 이것을 일반적인 첨부 파일 (포함되지 않음)로 해석합니다. Content-ID 행 을 완전히 제거하면 두 제품 모두 첨부 파일이 포함되어 있지 않다고 생각합니다.

어떤 행동이 옳은지를 결정적으로 결정하는 특정 RFC가 있습니까? 동료와 나는 오프닝 초록에서 다음과 같이 RFC2392를 검토했습니다.

이메일 내에서 [MIME]을 사용하여 웹 페이지 및
관련 이미지 를 전달 하려면 HTML
이 메시지에 포함 된 이미지 또는 기타 데이터 를 참조 할 수 있도록 URL 체계가 필요 합니다. Content-ID
Uniform Resource Locator 인 "cid :"가 그 목적을 달성합니다. "… cid"방식은 메시지의 특정 본문 부분을 나타냅니다. 그 사용은 일반적으로 참조 본문 부분과 동일한 메시지에서 다른 본문 부분에 대한 참조로 제한됩니다. "중간"방식은 또한 콘텐츠 ID의 주소를 포함함으로써 지정된 메시지 내의 특정 본문 부분을 지칭 할 수있다.

따라서 절대적인 것은 아니지만 모든 내장 된 항목은 참조 할 수있는 cid가 필요하기 때문에“일반적으로 같은 메시지에서 다른 신체 부위로 제한되어 있으며”첨부 파일 에는 cid가 필요 하지 않습니다. 전자 메일 제품이 cid의 존재를 "포함하려는 의도"의 지표로 취급하는 것이 합리적입니다.

이것에 대해 확인할 수 있습니까?


RFC 작성자 또는 관련 IETF WG에게 문의하십시오.
sendmoreinfo

답변:


8

Content-ID이미지가 인라인 표시해야 함을 표시하지 않습니다. 이 헤더는 HTML 내에 포함 된 데이터를 참조하는 데 필요합니다.

이메일은 문자 메시지이므로 메일이 일반 텍스트 인 한 이미지가 포함 된 이미지를 표시 할 이유가 없습니다.

일부 클라이언트는 형식이 HTML 또는 일반 텍스트인지에 관계없이 데이터를 인라인으로 표시합니다. 그러나 이것은 정의 된 행동이 아닙니다


8

난 당신이 찾고있는 생각 Content-Disposition당신이되고 (예 : 이미지로) 신체 부분의 프리젠 테이션 스타일을 정의 할 수 있습니다 헤더 필드, inline또는 attachment.

Thunderbird가 만든 인라인 예제는 다음과 같습니다.

--------------040202010204080305090405
Content-Type: image/png; name="test.png"
Content-Transfer-Encoding: base64
Content-ID: <part1.02080004.04000407@sample.com>
Content-Disposition: inline; filename="test.png"

자세한 내용은 다음을 참조하십시오.


콘텐츠 처리 헤더가 항상 포함되는 것은 아닙니다. 때로는 질문에 제공된 헤더를 기반으로 부품이 인라인인지 또는 첨부 파일인지를 도출해야합니다.
user2817219
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.