도메인 키 식별 메일

DomainKeys Identified Mail
인터넷 프로토콜 스위트
응용 프로그램레이어
트랜스포트 레이어
인터넷 레이어
링크 레이어

도메인 키 식별 메일(DKIM)은 피싱 및 전자 메일 스팸에 자주 사용되는 기술인 전자 메일에서 위조된 보낸 사람 주소를 탐지하도록 설계된 전자 메일 인증 방법입니다(전자 메일 스푸핑).

DKIM 에서는, 특정의 도메인으로부터 송신되었다고 주장되고 있는 전자 메일이,[1] 그 도메인의 소유자에 의해서 실제로 허가되고 있는 것을 수신자가 확인할 수 있습니다.각 발신 전자 메일 메시지에 도메인 이름에 링크된 디지털 서명을 첨부하여 이를 실현합니다.수신자 시스템은 DNS에 게시된 발신자의 공용 키를 조회하여 이를 확인할 수 있습니다.또한 유효한 서명은 서명 첨부 후 [2]이메일의 일부(아마도 첨부 파일 포함)가 변경되지 않았음을 보증합니다.일반적으로 DKIM 서명은 최종 사용자에게 표시되지 않으며 메시지의 작성자나 수신자가 아닌 인프라스트럭처에 의해 첨부 또는 검증됩니다.

DKIM은 인터넷 [3]표준입니다.2011년 9월호 RFC 6376에 정의되어 있으며 RFC 8301 및 RFC 8463에 업데이트가 포함되어 있습니다.

개요

가짜 주소와 콘텐츠가 쉽게 생성되고 스팸, 피싱 및 기타 이메일 기반 [4]사기에 널리 사용되기 때문에 이메일 인증의 필요성이 대두됩니다.예를 들어, 사기꾼은 수신자에게 이메일을 수신하고 읽도록 설득하기 위해 sender@example.com에서 왔다고 주장하는 메시지를 보낼 수 있습니다.수신자가 이 메시지를 신뢰할 수 있는지 여부를 결정하는 것은 어렵습니다.또한 시스템 관리자는 시스템에서 발생한 것으로 보이지만 실제로는 그렇지 [5]않은 악성 전자 메일에 대한 불만 사항을 처리해야 합니다.

DKIM은 메시지에 서명하는 기능을 제공하며 서명자(저작자 조직)가 합법적이라고 간주하는 전자 메일을 통신할 수 있도록 합니다.학대 행위를 직접적으로 예방하거나 공개하지는 않습니다.

DKIM은 서명된 메시지를 확인하는 프로세스도 제공합니다.확인 모듈은 일반적으로 각 홉에서 리시버 조직을 대표하여 동작합니다.

이 모든 것은 Simple Mail Transfer Protocol(SMTP) 라우팅 측면과는 무관합니다.이는 RFC 5321에 정의된 SMTP가 아닌 RFC 5322 메시지(전송 메일의 헤더와 본문)에서 작동하기 때문입니다.따라서 DKIM 시그니처는 여러 MTA에 걸친 기본 릴레이에서 살아남습니다.

기술적 세부사항

서명

서명 조직은 메시지의 직접 핸들러(작성자, 송신 사이트 또는 전송 경로의 다른 중간자 등) 또는 직접 핸들러를 지원하는 독립 서비스 등 간접 핸들러일 수 있습니다.

서명 모듈이 하나 이상 삽입됨DKIM-Signature:헤더 필드(작성자 조직 또는 발신기지 서비스 공급자를 대표할 수 있음)를 지정합니다.이 사양에 따라 서명자는 서명할 헤더필드를 선택할 수 있지만From:필드는 항상 [6][7]서명해야 합니다.결과 헤더 필드는 다음 목록으로 구성됩니다.tag=value다음 예시와 같은 부품:

DKIM-Signature: v=1; a=signature-sha256; d=example.net; s=sign; c=sign; q=sign/txt; i=foo@eng.example.net; t=1117574938; x=1118006938; l=200; h=signat:date:s; z=From:138 ~ foo@eng.example.netDemo:20Demo 실행 날짜:20Demo7월 = 19일 = 202005년 = 18일 : 44 : 08 = 20PM=20-0700; bh=MTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTI=; b=dzdVyOfAKCDLXdJOC9G2q8LoXslEniSbav+yuU4zGeruD00lsZ VoG4ZHRNiZR

여기서 사용되는 태그는 다음과 같습니다.

  • v(필수), 버전
  • (필수), 서명 알고리즘
  • d(필수), Signing Domain Identifier(SDID; 서명 도메인 식별자)
  • s(필수), 셀렉터
  • c(임의), 헤더 및 본문의 정규화 알고리즘
  • q(임의), 기본 쿼리 방식
  • i(옵션), 에이전트 또는 사용자 식별자(AUID)
  • t(권장), 시그니처 타임스탬프
  • x(권장), 유효기간
  • l(옵션), 본체 길이
  • h(필수), 헤더 필드 - 서명된 필드 목록
  • z(옵션), 헤더 필드 - 선택한 헤더 필드 및 값의 복사
  • bh(필수), 본문 해시
  • b(필수), 헤더와 본문의 시그니처

가장 관련성이 높은 것은 메일메시지 콘텐츠(헤더와 본문)의 실제 디지털시그니처 b, 본문 해시(옵션으로 본문의 첫 번째1 옥텟으로 한정), 서명 도메인 d, 실렉터입니다.

Agent 또는 User Identifier(AUID)는 옵션으로 포함할 수 있습니다.형식은 옵션의 로컬 파트가 포함된 전자 메일 주소입니다.도메인은 서명 도메인과 같거나 서명 도메인의 하위 도메인이어야 합니다.AUID의 시멘틱스는 의도적으로 정의되지 않은 상태로 유지되며, 서명 도메인이 보다 세밀한 책임 범위를 확립하기 위해 사용할 수 있습니다.

헤더와 본문 모두 시그니처에 기여합니다.첫 번째, 메시지 본문은 항상 처음부터 해시되며, 지정된 길이(0)로 잘릴 수 있습니다.다음으로 선택한 헤더필드는 h의 순서로 해시됩니다.반복된 필드명은 헤더 하단부터 위쪽으로 매칭됩니다.이 순서는,Received:필드는 헤더에 삽입됩니다.존재하지 않는 필드가 빈 문자열과 일치하므로 해당 이름을 가진 필드를 추가하면 시그니처가 끊어집니다.그DKIM-Signature:작성되는 시그니처의 필드(bh는 계산된 본문 해시, b는 빈 문자열)는 암묵적으로 두 번째 해시에 추가됩니다.단, 이름이 h로 표시되어서는 안 됩니다.표시되어 있는 경우는, 기존의 다른 시그니처를 참조합니다.두 해시 모두 관련 c 알고리즘에 따라 텍스트가 정규화됩니다.서명자의 개인 키로 암호화하고 Base64를 사용하여 인코딩한 결과 b가 됩니다.

h에 열거된 헤더 필드 리스트 외에 서명 시 존재하는 헤더 필드 리스트(필드 이름과 값 모두 포함)를 z로 제공해도 된다.이 목록은 h의 헤더 목록과 일치할 필요는 없습니다.

알고리즘, 필드 및 본문 길이는 명확한 메시지 식별을 보장하면서 시그니처가 전송 중에 발생할 수 있는 피할 수 없는 변경에도 대응할 수 있도록 선택하도록 되어 있습니다.엔드 투 엔드의 데이터 무결성은 암시되지 않습니다.[2]

검증

확인을 필요로 하는 수신측 SMTP 서버는, 도메인명과 실렉터를 사용해 DNS [8]검색을 실행합니다.예를 들어 위의 시그니처 예를 제시하겠습니다.d 태그는 검증 대상 작성자 도메인 example.net을 나타내고 s는 셀렉터인 브리즈번을 태그합니다.문자열 _domainkey는 사양의 고정 부분입니다.그러면 TXT 리소스 레코드는 다음과 같이 조회됩니다.

brisbane._domainkey.example.net

국제화 전자 [9]메일에서는, 실렉터와 도메인명을 UTF-8 로 할 수 있습니다.이 경우 라벨은 조회 전에 IDNA에 따라 부호화되어야 합니다.이 레코드의 쿼리에서 반환되는 데이터도 태그와 값의 쌍 목록입니다.도메인 공용 키와 함께 다른 키 사용 토큰 및 플래그(예: 명령줄에서):nslookup -q=TXT brisbane._domainkey.example.net)는 다음 예시와 같습니다.

"k=s, t=s, p=MIGfMA0GCSQGSIb3DQEBAQUAA4GNADCBiQKBgQDDmzRmJRQxLEyYiMg4suA2Sy MwR5MGHP9diNT1hRiwUd/Mzp1ro7kIDTKS8ttkI6z6eTRW9e9dDOxzSxNuXmume60Cjbu08gOyhPG3 GfWdg7QkdN6kR4V75MFlw624VY35DaXBNLTJgRg/EW72O1DiYVThkyCgpSYS8nmEQIDAQAB"

수신자는 공개 키(p 태그 값)를 사용하여 헤더필드의 해시 값에 대한 시그니처를 검증하고 수신된 메일메시지(헤더 및 본문)의 해시 값과 대조할 수 있습니다.두 값이 일치하는 경우 지정된 도메인에 의해 서명되었으며 전송 중에 변경되지 않았음을 암호화 방식으로 증명합니다.

서명 검증에 실패해도 메시지를 강제로 거부하지는 않습니다.대신 메시지의 신뢰성을 입증할 수 없었던 정확한 이유를 다운스트림 및 업스트림프로세스에서 사용할 수 있도록 해야 합니다.이 방법에는 RFC 7001에서 설명한 바와 같이 FBL 메시지를 반송하거나 Authentication-Results 헤더필드를 메시지에 추가하는 방법이 있습니다.

특허

DomainKeys는 미국 특허 6,986,049에 적용되지만 Yahoo!는 DomainKeys 특허 라이센스 계약 v1.[10]2 또는 GNU General Public License v2.0(다른 [11][12]버전은 제외)이라는 이중 라이센스 방식으로 특허 클레임을 라이센스했습니다.

SPF 및 DMARC와의 관계

기본적으로 DKIM과 SPF는 서로 다른 이메일 인증 척도를 제공합니다.DMARC는 조직에서 해당 도메인에서 전자 메일을 보낼 때 어떤 메커니즘(DKIM, SPF 또는 둘 다)을 사용하는지 지정하는 정책을 퍼블리시하는 기능, 최종 사용자에게 표시되는 From: 필드를 확인하는 방법, 수신자가 장애에 대처하는 방법 및 이러한 [13]정책에 따라 실행되는 액션에 대한 보고 메커니즘을 제공합니다.

이점

전자 메일 수신자에게 이 시스템의 주된 장점은 서명 도메인이 합법적인 전자 메일의 스트림을 확실하게 식별할 수 있도록 함으로써 도메인 기반 블랙리스트와 화이트리스트를 보다 효과적으로 [14]만들 수 있다는 것입니다.이것에 의해, 특정의 피싱 공격의 검출도 용이하게 됩니다.

메일 송신자가 발신 전자 메일에 서명하는 것에는 몇 가지 인센티브가 있습니다.

  • 이것에 의해, 전자 메일 수신기가 DKIM 시스템을 사용해 그 도메인으로부터 송신되었다고 주장하는 위조 전자 메일메시지를 특정하는 경우, DKIM 대응 도메인의 오용 데스크 업무를 큰폭으로 삭감할 수 있습니다.
  • 그러면 도메인 소유자는 악용 팀의 에너지를 실제로 해당 도메인을 부적절하게 사용하고 있는 사용자에게 집중할 수 있습니다.

스팸 필터링과 함께 사용

DKIM은 메시지에 라벨을 붙이는 방법으로 스팸 자체를 필터링하거나 식별하지는 않습니다.그러나 DKIM을 널리 사용하면 스팸 발송자가 오늘날 일반적으로 사용하는 기술인 메시지의 소스 주소를 위조하는 것을 방지할 수 있습니다.스팸 발송자가 올바른 소스 도메인을 표시하도록 강요받는 경우 다른 필터링 기술이 더 효과적으로 작동할 수 있습니다.특히 소스 도메인은 평판 시스템에 입력되어 스팸을 더 잘 식별할 수 있습니다.반대로 DKIM을 사용하면 스팸이 아닌 것으로 알려져 필터링할 필요가 없는 메일을 쉽게 식별할 수 있습니다.수신 시스템에 로컬로 유지 관리되거나 제3자 인증자의 알려진 정상적인 송신 도메인의 화이트리스트가 있는 경우, 해당 도메인의 서명된 메일에 대한 필터링을 건너뛰고 나머지 메일을 [14]보다 적극적으로 필터링할 수 있습니다.

안티피싱

DKIM은 피싱 방지 기술로 유용할 수 있다.피싱이 심한 도메인의 메일 발송자는 메일이 진짜임을 나타내는 서명에 서명할 수 있습니다.수신인은 해당 도메인의 메일에 유효한 서명이 없는 것으로 간주하여 메일이 위조되었을 수 있습니다.이 정도의 정밀 조사를 실시할 가치가 있는 도메인 세트를 결정하는 최선의 방법은 아직 미해결인 채로 있습니다.DKIM은 모든 우편물에 서명하는 작성자가 본인임을 확인할 수 있는 ADSP라는 옵션 기능을 갖추고 있었지만 2013년 [15]11월 역사로 강등됐다.대신 DMARC를 같은 목적으로[16] 사용할 수 있으며 도메인이 어떤 기술(SPF 및 DKIM 포함)을 사용하는지 자체 퍼블리시할 수 있습니다.이것에 의해, 수신자는, 특정의 메일이 스팸인지 [17]아닌지를, 정보에 근거해 판단하기 쉬워집니다.예를 들어 DMARC, eBay, PayPal을 사용하는 것은 모두 모든 메일이 인증되는 정책을 발표하고 Gmail과 같은 수신 시스템이 인증되지 않은 [18]것을 거부하도록 요청합니다.

호환성.

DNS 레코드와 추가된 RFC 5322 헤더필드를 사용하여 구현되므로 DKIM은 기존 전자 메일인프라스트럭처와 호환성이 있습니다.특히 DKIM 지원이 [19]없는 기존 이메일 시스템에 대해 투명합니다.

이 설계 방식은 S/MIME 및 OpenPGP 콘텐츠 보호 표준 등 다른 관련 서비스와도 호환됩니다.DKIM은 DNSSEC 표준 및 SPF와 호환됩니다.

계산 오버헤드

DKIM 에서는 메일서버를 경유하여 송신되는 각 메시지에 대해 암호화 체크섬을 생성해야 합니다.이것에 의해, 전자 메일의 전달에는 별도로 필요 없는 계산 오버헤드가 발생합니다.이러한 추가적인 계산 오버헤드는 디지털 우편물의 특징이며 대량 스팸을 보내는 비용이 ([20]계산적으로).DKIM의 이러한 측면은 수신측 검증이 무시해도 될 정도의 작업량인 반면 일반적인 해시 캐시 알고리즘은 훨씬 [citation needed]더 많은 작업을 필요로 한다는 점을 제외하면 해시 캐시와 비슷해 보일 수 있습니다.

거부 불능

DKIM의 거부 방지 기능은 보낸 사람(스패머 등)이 전자 메일 발송을 확실하게 거부하는 것을 방지합니다.WikiLeaks와 같은 뉴스 매체에서는 DKIM의 본문 서명을 활용하여 유출된 이메일이 조작되지 않고 진품임을 증명할 수 있었습니다.예를 들어 힐러리 클린턴의 2016년 미국 대통령 선거 러닝메이트 팀 케인과 DNC 의장 도나 [21]브레이즐은 이러한 주장을 완전히 부인했습니다.

약점

RFC 자체에서 잠재적인 공격 [22]벡터가 다수 식별됩니다.

DKIM 시그니처는 리턴 경로 및 메시지 수신인을 유지하는 메시지엔벨로프를 포함하지 않습니다.DKIM은, 주소의 잘못에 대해서 보호하려고 하지 않기 때문에, DKIM의 유틸리티에는 영향을 주지 않습니다.

2013년 표준화 [23]당시 많은 우려가 제기되었고 반박되었다.

모든 암호화 솔루션에서 우려되는 것은 메시지 리플레이 남용입니다.이는 현재 대규모 도메인에서 [clarification needed]악용되는 수준을 제한하는 기술을 우회합니다.재생은 메시지별 공용 키를 사용하여 해당 키의 DNS 쿼리를 추적하고 전자 메일이 대규모 메일링 목록에 전송되거나 잘못된 액터에 의해 악의적인 쿼리에 의해 많은 수의 쿼리를 필터링함으로써 추론할 수 있습니다.

이 문제에 대처하는 다양한 방법의 비교에 대해서는, E-메일 인증을 참조해 주세요.

임의 전송

위에서 설명한 바와 같이 인증은 남용 방지와 동일하지 않습니다.평판 있는 도메인의 악의적인 전자 메일 사용자는 잘못된 메시지를 작성하고 DKIM에 서명하여 해당 도메인에서 파일로서 가져올 수 있는 우편함으로 전송하여 메시지의 서명된 복사본을 얻을 수 있습니다.시그니처에 l 태그를 사용하면 이러한 메시지를 조작하기가 더욱 쉬워집니다.서명된 복사본은 예를 들어 봇넷을 통해 제어 없이 백만 명의 수신자에게 전송할 수 있습니다.메시지에 서명한 전자 메일 공급자는 위반 사용자를 차단할 수 있지만 이미 서명된 메시지의 확산을 막을 수는 없습니다.이러한 메시지의 시그니처의 유효성은 시그니처에 항상 유효기간 태그를 포함하거나 정기적으로 공개키를 취소하거나 사고에 대한 통지에 의해 제한할 수 있습니다.송신 메일을 필터링 하는 것으로, 이 시나리오의 유효성은 거의 제한되지 않습니다.이는 메시지가 스팸 [24]발송자에게 유용할 수 있는지 여부를 검출하는 기능을 의미합니다.

콘텐츠 수정

DKIM은 현재 두 가지 표준화 알고리즘을 갖추고 있습니다.심플하고 릴렉스하며, 어느 쪽도 MIME을 [25]인식하지 않습니다.메일 서버는 합법적으로 다른 문자 집합으로 변환할 수 있으며, 종종 X-MIME-Autoconverted 헤더 필드로 이를 문서화합니다.또한 특정 상황에서 서버는 MIME 구조를 다시 작성해야 합니다.그 결과 프리암블, 에필로그 및 엔티티 경계를 변경할 수 있습니다.이 경계는 모두 DKIM 시그니처를 파괴합니다.MIME 헤더필드에 [26]서명이 없는 경우 us-ascii로 작성된 플레인텍스트 메시지만 엔드 투 엔드의 정합성에 필요한 견고성을 누릴 수 있습니다.

OpenDKIM 프로젝트는 21개의 메일 서버와 수백만 개의 메시지를 포함하는 데이터 수집을 구성했습니다. 관찰된 서명의 92.3%가 성공적으로 검증되었습니다. 이는 메일 목록 트래픽만 고려할 [27]때 성공률이 약간(90.5%) 떨어집니다.

메일 목록별 주석

필터링 또는 릴레이 소프트웨어가 메시지를 변경하면 문제가 더욱 심각해질 수 있습니다.송신자가 특별히 주의하지 않으면 대부분의 메일링 리스트와 많은 중앙 안티바이러스 솔루션에 의해 푸터가 추가되면 DKIM 시그니처가 파손됩니다.가능한 경감 방법은 메시지 본문의 지정된 바이트 수만 서명하는 것입니다.DKIM-Signature 헤더에 l 태그가 붙어 있습니다.DKIM 시그니처를 계산할 때 메시지 본문의 지정된 길이를 초과하여 추가된 내용은 고려되지 않습니다.MIME [28]메시지에는 사용할 수 없습니다.

또 다른 회피책은 기존의 포워더(SPF 등)를 화이트리스트로 하는 것입니다.또 다른 회피책으로는 Forwarder가 서명을 확인하고 전자 메일을 수정한 다음 Sender: [29]헤더를 사용하여 메시지에 다시 서명하는 것이 제안되었습니다.단, 이 솔루션에는 RFC 5617 ADSP 프로토콜을 지원하는SMTP 리시버에서 수신된 전송된 서드파티 서명 메시지에 대한 리스크가 있습니다.따라서 실제로는 수신 서버는 기존의 메시지스트림을 화이트리스트에 남겨야 합니다.

ARC(Authenticated Received Chain)는 메일 목록이나 포워딩 서비스와 같은 중간 메일 서버가 전자 메일의 원래 인증 결과에 서명할 수 있도록 설계된 전자 메일 인증 시스템입니다.이를 통해 수신 서비스는 중간 서버의 [30]처리로 인해 이메일의 SPF 및 DKIM 레코드가 비활성화되었을 때 이메일을 검증할 수 있습니다.ARC는 2019년 7월에 발행된 RFC 8617에서 "Experimental"[31]로 정의되어 있습니다.

단축키 취약성

2012년 10월, Wired는 수학자 Zach Harris가 짧은 DKIM 키를 사용하여 이메일 소스 스푸핑의 취약성을 검출하고 시연했다고 보고했습니다.google.com기업 도메인과 다른 하이 프로파일 도메인이 있습니다.그는 384비트 키를 사용한 인증은 "노트북에서" 24시간 이내에, 512비트 키를 사용한 인증은 클라우드 컴퓨팅 리소스에서 약 72시간 내에 완료할 수 있다고 말했습니다.Harris는 많은 조직이 이러한 단축키를 사용하여 이메일에 서명하고 있음을 알게 되었습니다.Harris는 이 모든 것을 감안하여 조직에 취약성을 통지했습니다.그는 768비트 키가 매우 큰 컴퓨팅 파워에 액세스 할 때 고려될 수 있으므로 DKIM 서명은 1,024비트보다 긴 키를 사용해야 한다고 제안합니다.

와이어드는 해리스가 보고했고 구글은 그의 공개 직후에 새로운 긴 키를 사용하기 시작했다고 밝혔다.RFC 6376에 따르면 수신측은 512비트~2048비트의 키를 사용하여 시그니처를 검증할 수 있어야 합니다.따라서 512비트보다 짧은 키의 사용은 호환되지 않을 수 있으므로 피해야 합니다.또, RFC 6376에서는, 서명자는,[32] 롱 라이프 타임을 명시하고 있지 않지만, 롱 라이프 타임을 위해서 적어도 1024 비트의 키를 사용할 필요가 있습니다.

역사

DKIM은 2004년에 야후의 "확장 도메인 키"와 [33][34]시스코의 "식별된 인터넷 메일"이라는 두 가지 유사한 작업을 통합한 결과입니다.IETFstandards-track 사양과 지원 서류의 결국 성병 76에, 현재는 6376 시리즈 이 통합 규격 기본이 되어 왔다.반면 DomainKeys Yahoo[38][39]에 의한 e.의 DNS도메인을 확인하도록 설계되었다[35]"인터넷 메일 식별"시스코에 의한signature-based 메일 인증 standard,[36][37]로 제안되었다-메일 발송인과 메시지 무결성.

도메인 키의 일부와 식별된 인터넷 메일이 결합되어 도메인 키 식별 메일(DKIM)[38][40][41]이 작성되었습니다.DKIM을 구현하는 트렌드 설정 제공업체에는 야후, Gmail, AOL 및 FastMail이 포함됩니다.이러한 조직으로부터의 메일에는 DKIM [38][42][43][44]서명이 포함되어 있어야 합니다.

DMARC 워킹 그룹에서 공식적으로 DKIM 서명이 간접 메일 흐름을 통과하는 것에 대한 논의는 새로운 프로토콜의 첫 번째 채택이 일반적인 메일 목록 사용에 대혼란을 일으킨 직후에 이루어졌다.그러나 제안된 DKIM 변경은 통과되지 않았습니다.대신 메일링 리스트 소프트웨어가 변경되었습니다.[45]

2017년에는 서명기법 [46]검토에 특별한 제한을 두고 또 다른 워킹그룹인 DKIM Crypto Update(dcrup)가 출범하였다.RFC 8301은 2018년 1월에 발행되었습니다.SHA-1을 금지하고 키 크기(512-2048 ~1024-4096)[47]를 업데이트합니다.RFC 8463은 2018년 9월에 발행되었습니다.기존 RSA에 타원곡선 알고리즘을 추가합니다.추가된 키 유형,k=ed25519에는 짧은 공개 키가 탑재되어 있어 DNS에서 [48]보다 쉽게 퍼블리시할 수 있습니다.

발전

오리지널 DomainKeys는 Yahoo!의 Mark Delany에 의해 설계되었으며 2004년 이후 많은 다른 업체들의 코멘트를 통해 강화되었다.이는 2007년 5월에 발표된 Standards Track RFC 4871, DomainKeys Identified Mail(DKIM) Signatures로 대체된 이력 RFC 4870에 규정되어 있습니다.그 후 많은 설명과 개념화가 수집되어 RFC 5672, 2009년 8월에 기존 사양을 수정하는 형태로 규정되었다.2011년 9월, RFC 6376은 DKIM 프로토콜의 본질을 유지하면서 후자의 두 문서를 통합 및 업데이트했습니다.이전 도메인 키와의 공개 키 호환성도 가능합니다.

DKIM은 처음에는 비공식 업계 컨소시엄에 의해 제작되었으며, 그 후 IETF DKIM Working Group에 의해 강화 및 표준화를 위해 제출되었습니다.배리 라이바와 스티븐 패럴이 의장을 맡았으며, Eric Allman of sendmail, JGP Corporation, Mark Delany 및 Miles Libbey of Jim!주요 저자로 간주됩니다.

하나의 공통 라이브러리의 소스 코드 개발은 OpenDKIM 프로젝트에 의해 주도되며, 최신 프로토콜 추가 및 새로운 BSD [49]라이센스에 따른 라이센싱이 이루어집니다.

「 」를 참조해 주세요.

레퍼런스

  1. ^ Tony Hansen; Dave Crocker; Phillip Hallam-Baker (July 2009). DomainKeys Identified Mail (DKIM) Service Overview. IETF. doi:10.17487/RFC5585. RFC 5585. Retrieved 6 January 2016. Receivers who successfully verify a signature can use information about the signer as part of a program to limit spam, spoofing, phishing, or other undesirable behaviors. DKIM does not, itself, prescribe any specific actions by the recipient; rather, it is an enabling technology for services that do.
  2. ^ a b Dave Crocker; Tony Hansen; Murray S. Kucherawy, eds. (September 2011). "Data Integrity". DomainKeys Identified Mail (DKIM) Signatures. IETF. sec. 1.5. doi:10.17487/RFC6376. RFC 6376. Retrieved 6 January 2016. Verifying the signature asserts that the hashed content has not changed since it was signed and asserts nothing else about "protecting" the end-to-end integrity of the message.
  3. ^ Crocker, D.; Hansen, T.; Kucherawy, M. "DomainKeys Identified Mail (DKIM) Signatures". RFC Editor. ISSN 2070-1721. Retrieved 30 March 2020.
  4. ^ "DKIM: What is it and why is it important?". postmarkapp.com. Retrieved 19 February 2022.
  5. ^ Jason P. Stadtlander (16 January 2015). "Email Spoofing: Explained (and How to Protect Yourself)". HuffPost. Retrieved 11 January 2016.
  6. ^ Dave Crocker; Tony Hansen; Murray S. Kucherawy, eds. (July 2009). "Determine the Header Fields to Sign". DomainKeys Identified Mail (DKIM) Signatures. IETF. sec. 5.4. doi:10.17487/RFC6376. RFC 6376. Retrieved 6 January 2016. The From header field MUST be signed (that is, included in the "h=" tag of the resulting DKIM-Signature header field).
  7. ^ 서명 모듈은 키 쌍의 개인 절반을 사용하여 서명을 수행하고 다음 "확인" 섹션에서 설명한 대로 DNS TXT 레코드에 공개합니다.
  8. ^ DKIM 키 관리에 관련된 CA나 해지 목록은 없으며, 실렉터는 서명자가 원할 때 언제든지 키를 추가 및 삭제할 수 있는 간단한 방법입니다.어카이브(archive) 목적의 장기 서명은 DKIM의 범위 밖입니다.
  9. ^ John Levine (June 2019). "DKIM and Internationalized Mail". Email Authentication for Internationalized Mail. IETF. sec. 5. doi:10.17487/RFC8616. RFC 8616.
  10. ^ "Yahoo! DomainKeys Patent License Agreement v1.1". SourceForge. 2006. Retrieved 30 May 2010. Yahoo! DomainKeys Patent License Agreement v1.2
  11. ^ Levine, John R. (25 January 2010). "IPR disclosures, was Collecting re-chartering questions". ietf-dkim mailing list. Mutual Internet Practices Association. Retrieved 30 May 2010. The reference to the GPL looks to me like it only covers the old Sourceforge DK library, which I don't think anyone uses any more. The patent, which is what's important, is covered by a separate license that Yahoo wrote.
  12. ^ Chen, Andy (26 September 2011). "Yahoo! Inc.'s Statement about IPR related to RFC 6376". IPR disclosure. IETF. Retrieved 3 October 2011.
  13. ^ "History". dmarc.org.
  14. ^ a b Falk, J.D. (17 March 2009). "Searching for Truth in DKIM". CircleID.
  15. ^ Barry Leiba (25 November 2013). "Change the status of ADSP (RFC 5617) to Historic". IETF. Retrieved 13 March 2015.
  16. ^ "FAQ - DMARC Wiki". The DMARC standard states in Section 6.7, “Policy Enforcement Considerations,” that if a DMARC policy is discovered the receiver must disregard policies advertised through other means such as SPF or ADSP.
  17. ^ "Add a DMARC record - Google Apps Administrator Help".
  18. ^ "About DMARC - Google Apps Administrator Help". Your policy can be strict or relaxed. For example, eBay and PayPal publish a policy requiring all of their mail to be authenticated in order to appear in someone's inbox. In accordance with their policy, Google rejects all messages from eBay or PayPal that aren’t authenticated.
  19. ^ Tony Hansen; Dave Crocker; Phillip Hallam-Baker (July 2009). DomainKeys Identified Mail (DKIM) Service Overview. IETF. doi:10.17487/RFC5585. RFC 5585. Retrieved 1 July 2013.
  20. ^ Roic, Alessio (2007년 7월 5일)「Postmarking: 스팸 대책 지원」2011년 7월 17일 Wayback Machine에서 아카이브.Microsoft Office Outlook 블로그
  21. ^ "DKIM Verification". www.wikileaks.org. 4 November 2016. Retrieved 7 November 2016.
  22. ^ D. Crocker; T. Hansen; M. Kucherawy. "Security considerations". DomainKeys Identified Mail (DKIM) Signatures. IETF. sec. 8. doi:10.17487/RFC6376. RFC 6376.
  23. ^ "IESG Report regarding "Appeal of decision to advance RFC6376"". IETF.org. IETF. Retrieved 26 December 2018.
  24. ^ Jim Fenton (September 2006). "Chosen Message Replay". Analysis of Threats Motivating DomainKeys Identified Mail (DKIM). IETF. sec. 4.1.4. doi:10.17487/RFC4686. RFC 4686. Retrieved 10 January 2016.
  25. ^ Ned Freed (with agreement by John Klensin) (5 March 2010). "secdir review of draft-ietf-yam-rfc1652bis-03". YAM mailing list. IETF. Retrieved 30 May 2010. DKIM WG opted for canonical form simplicity over a canonical form that's robust in the face of encoding changes. It was their engineering choice to make and they made it.
  26. ^ RFC 2045에서는 파라미터 값을 토큰 또는 따옴표로 묶은 문자열로 할 수 있습니다.예를 들어 {{1}}에서는 따옴표가 법적으로 삭제되어 DKIM 시그니처가 파손됩니다.
  27. ^ Kucherawy, Murray (28 March 2011). "RFC4871 Implementation Report". IETF. Retrieved 18 February 2012.
  28. ^ Murray S. Kucherawy (September 2011). DomainKeys Identified Mail (DKIM) and Mailing Lists. IETF. doi:10.17487/RFC6377. RFC 6377. Retrieved 10 January 2016.
  29. ^ Eric Allman; Mark Delany; Jim Fenton (August 2006). "Mailing List Manager Actions". DKIM Sender Signing Practices. IETF. sec. 5.1. I-D draft-allman-dkim-ssp-02. Retrieved 10 January 2016.
  30. ^ "Authenticated Received Chain Overview" (PDF). Retrieved 15 June 2017.
  31. ^ K. Andersen; B. Long; S. Blank; M. Kucherawy. The Authenticated Received Chain (ARC) Protocol. IETF. doi:10.17487/RFC8617/. RFC 8617/.
  32. ^ 김제터(2012년 10월 24일)."구글 헤드헌터의 이메일이 거대한 인터넷 보안 구멍을 어떻게 해결했는지"유선. 2012년 10월 24일 접속.
  33. ^ "DKIM Frequently Asked Questions". DKIM.org. 16 October 2007. Retrieved 4 January 2016. DKIM was produced by an industry consortium in 2004. It merged and enhanced DomainKeys, from Yahoo! and Identified Internet Mail, from Cisco.
  34. ^ Jim Fenton (15 June 2009). "DomainKeys Identified Mail (DKIM) Grows Significantly". Cisco. Archived from the original on 24 December 2014. Retrieved 28 October 2014.
  35. ^ "STD 76, RFC 6376 on DomainKeys Identified Mail (DKIM) Signatures". IETF. 11 July 2013. Retrieved 12 July 2013. RFC 6376 has been elevated to Internet Standard.
  36. ^ "Identified Internet Mail: A network based message signing approach to combat email fraud". 26 April 2006. Archived from the original on 27 April 2006. Retrieved 4 January 2016.
  37. ^ Jim Fenton; Michael Thomas (1 June 2004). Identified Internet Mail. IETF. I-D draft-fenton-identified-mail-00. Retrieved 6 January 2016.
  38. ^ a b c 델라니, 마크(2007년 5월 22일)."이메일에 대한 작은 발걸음, 인터넷 안전에 대한 큰 도약"야후! 기업 블로그델라니는 DomainKeys의 발명가이자 최고 설계자로 인정받고 있습니다.
  39. ^ "Yahoo Releases Specs for DomainKeys". DMNews.com.
  40. ^ RFC 4870(DNS(DomainKeys)에서 애드버타이즈된 공개키를 사용한 도메인 기반 이메일 인증), RFC 4871에 의해 폐지되었습니다.
  41. ^ RFC 6376('DomainKeys Identified Mail(DKIM)' 시그니처, RFC 4871 및 RFC 5672 폐지)
  42. ^ Taylor, Brad (2008년 7월 8일)"eBay 및 Paypal을 통한 피싱 퇴치"Gmail 블로그
  43. ^ "Gmail로 메시지 보내는 데 문제가 있어요"Gmail 도움말 항목, 전송 시 DKIM 지원을 언급합니다.
  44. ^ Mueller, Rob (2009년 8월 13일)"모든 아웃바운드 이메일이 DKIM에 서명되었습니다."패스트 메일 블로그
  45. ^ "DMARC Group History". IETF.
  46. ^ "DKIM Crypto Update (dcrup)". IETF.
  47. ^ Scott Kitterman (January 2018). Cryptographic Algorithm and Key Usage Update to DomainKeys Identified Mail (DKIM). IETF. doi:10.17487/RFC8301. RFC 8301.
  48. ^ John Levine (September 2018). A New Cryptographic Signature Method for DomainKeys Identified Mail (DKIM). IETF. doi:10.17487/RFC8463. RFC 8463.
  49. ^ "OpenDKIM".

추가 정보

  • RFC 4686 도메인키 식별 메일(DDIM)을 유발하는 위협 분석
  • RFC 4871 도메인키 식별 메일(DKIM) 시그니처 제안 표준
  • RFC 5617 도메인키 식별 메일(DDIM) 작성자 도메인 서명 프랙티스(ADSP)
  • RFC 5585 도메인키 식별 메일(DKIM) 서비스의 개요
  • RFC 5672 RFC 4871 도메인키 식별 메일(DKIM) 시그니처: 갱신
  • RFC 5863 DKIM의 개발, 전개 및 운용
  • RFC 6376 도메인키 식별 메일(DDIM) 서명 초안 규격
  • RFC 6377 도메인키 식별 메일(DDIM) 및 메일링 리스트
  • RFC 8301 도메인키 식별 메일(DKIM) 암호화 알고리즘 및 키 사용률 업데이트
  • RFC 8463 도메인키 식별 메일(DKIM)의 새로운 암호화 서명 방법

외부 링크