This page (revision-1) was last changed on 29-Nov-2024 16:16 by UnknownAuthor

Only authorized users are allowed to rename pages.

Only authorized users are allowed to delete pages.

Page revision history

Version Date Modified Size Author Changes ... Change note

Page References

Incoming links Outgoing links
DomainKeys Identified Mail
DomainKeys Identified Mail

Version management

Difference between version and

At line 1 added 476 lines
!!! Overview
[{$pagename}] ([DKIM]) is an [email] [authentication] [Protocol] designed to detect forged sender addresses in [emails] (email spoofing), a technique often used in [phishing] and [email] [spam] is defined in [RFC 6376]
[DKIM] allows the receiver to check that an email claimed to have come from a specific domain was indeed authorized by the owner of that domain.[1] It achieves this by affixing a digital signature, linked to a domain name, to each outgoing email message. The recipient system can verify this by looking up the sender's public key published in the DNS. A valid signature also guarantees that some parts of the email (possibly including attachments) have not been modified since the signature was affixed.[2] Usually, DKIM signatures are not visible to end-users, and are affixed or verified by the infrastructure rather than the message's authors and recipients.
!! [{$pagename}] [Implementation]
! Signing
The signing organization can be a direct handler of the message, such as the author, the submission site or a further intermediary along the transit path, or an indirect handler such as an independent service that is providing assistance to a direct handler.
Signing modules insert one or more DKIM-Signature: header fields, possibly on behalf of the author organization or the originating service provider. The specification allows signers to choose which header fields they sign, but the From: field must always be signed. The resulting header field consists of a list of tag=value parts as in the example below:
{{{DKIM-Signature: v=1; a=rsa-sha256; d=example.net; s=brisbane;
c=relaxed/simple; q=dns/txt; t=1117574938; x=1118006938;
h=from:to:subject:date:keywords:keywords;
bh=MTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTI=;
b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZ
VoG4ZHRNiYzR}}}
Where the tags used are:
* v, version
* a, signing algorithm
* d, domain
* s, selector
* c, canonicalization algorithm(s) for header and body
* q, default query method
* t, signature timestamp
* x, expire time
* h, header fields - list of those that have been signed
* bh, body hash
* b, signature of headers and body
The most relevant ones are b for the actual [Digital Signature] of the contents (headers and body) of the [email] [message], bh for the body [hash], d for the signing domain, and s for the selector.
Both header and body contribute to the [Digital Signature]. First, the message body is [hashed|Hash], always from the beginning, possibly truncated at a given length (which may be zero). Second, selected header fields are [hashed|Hash], in the order given by h. Repeated field names are matched from the bottom of the header upward, which is the order in which Received: fields are inserted in the header. A non-existing field matches the empty string, so that adding a field with that name will break the signature. The DKIM-Signature: field of the signature being created, with bh equal to the computed body hash and b equal to the empty string, is implicitly added to the second [hash], albeit its name must not appear in h — if it does, it refers to another, preexisting signature. For both hashes, text is canonicalized according to the relevant c algorithms. The result, after encryption with the signer's [Private Key] and [encoding] using [Base64], is b.
[Algorithms], fields, and body length are meant to be chosen so as to assure unambiguous [message] identification while still allowing [Digital Signatures] to survive the unavoidable changes which are going to occur in transit. __No data integrity is implied__.
!! Verification
A receiving [SMTP] [server] wanting to verify uses the [DNS Domain] name and the selector to perform a [DNS] lookup. For example, given the example signature above:
* the d tag gives the author domain to be verified against, example.net ;
* the s tag the selector, brisbane.
* the string _domainkey is a fixed part of the specification.
This gives the TXT [DNS Resource Record] to be looked up as:
{{{brisbane._domainkey.example.net}}}
The data returned from the query of this record is also a list of tag-value pairs. It includes the domain's [Public Key], along with other key usage tokens and flags; as in this [example]:
{{{"k=rsa; t=s; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDDmzRmJRQxLEuyYiyMg4suA2Sy
MwR5MGHpP9diNT1hRiwUd/mZp1ro7kIDTKS8ttkI6z6eTRW9e9dDOxzSxNuXmume60Cjbu08gOyhPG3
GfWdg7QkdN6kR4V75MFlw624VY35DaXBvnlTJTgRg/EW72O1DiYVThkyCgpSYS8nmEQIDAQAB"}}}
The receiver can use the [Public Key] (value of the p tag) to then decrypt the [hash] value in the header field, and at the same time recalculate the [hash] value for the mail [message] (headers and body) that was received. If the two values match, this [cryptographically|Cryptography] proves that the [email] was signed by the indicated domain and has not been tampered with in transit.
Signature verification failure does not force rejection of the message. Instead, the precise reasons why the authenticity of the message could not be proven should be made available to downstream and upstream processes. Methods for doing so may include sending back an FBL message, or adding an Authentication-Results header field to the message as described in RFC 7001.
!! [{$pagename}] [Patent]
Although DomainKeys is covered U.S. Patent 6,986,049, [Yahoo]! has licensed its [patent] claims under a dual license scheme: the DomainKeys Patent License Agreement v1.2,[9] or [GNU General Public License] v2.0 (and no other version).
!! More Information
There might be more information for this subject on one of the following:
[{ReferringPagesPlugin before='*' after='\n' }]
----
* [#1] - [DomainKeys Identified Mail|Wikipedia:DomainKeys_Identified_Mail|target='_blank'] - based on information obtained 2019-07-18
This page (revision-1) was last changed on 29-Nov-2024 16:16 by UnknownAuthorTop