provenance and contents of an email.
semantics of Internet email as it is known today.
DomainKeys Identified Mail [DKIM] specification has been derived.
for deployed implementations written prior to the DKIM specification.
others from abusing your identity.
other words, authentication is as much about protection as proof.
the sender, since senders can trivially assume any email address.
dispositional control of email to the recipient.
email" is the content that the recipient sees.
credible domain-level authentication for email.
system authorized to send email for that domain.
given domain, you have control over your DomainKeys for that domain.
key-fetching services as they become available.
AUTH or other identifying mechanisms.
to notify the MUA in some way -- typically via a header line.
recording authentication results in the email.
sufficient to complete the implementation.
systems, reputations systems, and their ilk can be developed.
03    25 Subject: Is dinner ready?
11    37 We lost the game. Are you hungry yet?
Lines 05 and 06 constitute the "Comment:" header.
Line 06 is a continuation header line.
Line 07 is the last line of the headers.
Line 08 is the empty line that separates the header from the body.
Line 09 is the first line of the body.
Lines 10, 12, 14, and 15 are empty lines.
Line 13 is the last non-empty line of the email.
Line 15 is the last line of the body and the last line of the email.
Lines 01 to 15 constitute the complete email.
Line 01 is earlier than line 02, and line 02 is later than line 01.
2. Fetch the public key from the claimed sending domain namespace.
policy based on the results of the signature test.
Given an email, how is the sending domain determined?
How is the public key retrieved for a sending domain?
signature and how are they protected from such transformations?
How is the signature represented in the email?
the recipient determine the policy intent of the sending domain?
result conveyed to participating MUAs?
implementations will require changes to participate in DomainKeys.
domain most visible to the recipient.
domain name can be extracted.
from which an email address with a domain name can be extracted.
the signer MUST use the sending address in the "Sender:" header.
signer MUST use the first sending address in the "From:" header.
should note that an email with a "Sender:" header and no "From:"
header MUST NOT be signed.
and key pairs in different regions, or on different email servers.
"2006" private key.  At the end of the transition period, the "2005"
public key is removed from the DNS.
This public key data is placed in the DNS.
sending address.  This tag is optional.
support the 'rsa' key type.  This tag is optional.
is made by any program.  This tag is optional.
a TXT record can accommodate a 2048 bit key.
to the explanation and remove the public key value from the "p" tag.
are no larger than 1024 bits.
The signature of the email is stored in the "DomainKey-Signature:"
whitespace in this value to conform to line-length limits.
be one of the parent domains of the sending email address.
Domain name comparison is case insensitive.
or subdomain of the value.
presented to the signing algorithm.
identify the sending domain, i.e., the "From:" or "Sender:"
header; thus, this tag can never contain an empty value.
signature header are included in the order found in the email.
Signature:" header in the verification.
do not try to "look" back before the "DomainKey-Signature:"
document.  Verifiers and signers MUST support "dns".
trusted, as this header is not protected by the signature.
audit information describing the initial submission.
predicted and consequently accounted for when signing and verifying.
most common and minor changes made to email.
transport, particularly pertaining to line lengths and 8-bit content.
accept 8-bit email and long lines, some implementations still do not.
presenting the email for signing.
whitespace replacement and header line rewrapping.
verifier MUST be able to process email using either algorithm.
the headers to the last line of the body.
continuation lines if any) added to the "h" tag list are included.
body lines, which are always included.
o  Remove any local line terminator.
o  Append CRLF to the resulting line.
zero length after removal of the local line terminator.
removed from all lines and header continuation lines are unwrapped.
of the headers to the last line of the body.
are processed as a single line.
header/body line is similarly ignored.
define the complete process of signing an email.
it MUST NOT be signed.
reasons why a signer may choose not to sign an email.
authorized to use the sending domain.
this occurs is with mailing lists.
A signer SHOULD NOT remove an existing "DomainKey-Signature:" header.
preparation for signing and transmission.
process of transmitting the email.
whether it signs all outbound email.
is made by any program.
testing mode results to assist the sender).
is running a DomainKeys test.
if a domain policy indicates that it signs all email.
be rejected by some receiving MTAs.
being during acceptance or local delivery by the MTA.
is ascertained to assist in applying local policy.
signature added to the email and thus is the one to be verified.
never there, or was it removed by an overzealous filter?
regardless of whether or not it looks like it was signed.
use and SHOULD ignore all other signatures.
fails, the email SHALL fail verification.
this extraction fails, the email SHALL fail verification.
that are coded with an unrecognized signing algorithm.
preference to later signature headers.
accept" is definitely a bad strategy in this security context.
defined by the "q" tag in the "DomainKey-Signature:" header line.
extracting the signature information is completely successful.
"_domainkey" namespace and the domain name defined by the "d"
tag, construct and issue the DNS TXT record query string.
achieved with a 4XX SMTP response code).
is not needed until the final RSA is calculated.
Armed with the signature information from the "DomainKey-Signature:"
signature of the email can now be verified.
defines which verification algorithm to use.
but it MAY include rejecting the email.
line prepended to the email.
imply that the verification could not be performed for some reason.
spoofing attempts can only serve to demote themselves.
also perform this verification if they choose to do so.
The verification process uses the domain "football.example.com"
verifying with the "simple" method.
containing their public key -- often for a recurring fee.
used to sign the email and the certificate issued by a CA.
header contains a URL that points to a certificate issued by a CA.
certificate matches the public key used to sign the email.
nor is the determination of valid CAs.
possible to a higher authority.
potentially hundreds of keys via their unique selectors.
a separate DomainKey for each regional office email server.
key and selector to the third party for the life of the mail-out.
the entry from the DNS.
of cryptographic signatures - to detect modifications.
make minimal or no modifications to an email.
prior to signing for distribution to list recipients.
fail MAY perform the same actions as a modifying MLM.
email server to send email.
time, such email will be treated as second-class email.
DomainKeys.  Per-user DomainKeys are identified by a non-empty "g"
tag value in the corresponding DNS record.
DNS, which has well-known security flaws [RFC3833].
attacks of this nature is expected to be uneconomical.
such as GnuPG and S/MIME address those requirements.
because the implementors used predictable "random numbers".
higher duty of care to manage the increased risk.
signature can provide additional information to the sender.
by the forwarding and delivery MTAs.
denial-of-service attack more effective against a mail system.
does not add a non-linear component to such attacks.
numerous implementations, both Open Source and commercial.
the Internet each day between some 12,000 participating domains.
Procedures", RFC 1421 February, 1993.
o  A tag=value pair consists of three tokens, a "tag", the "="
of characters from SPACE (0x20) to TILDE (0x7E) inclusive.
Values MUST NOT contain a semicolon but they may contain "="
tag description of semantics imply case insensitivity.
specifically ignore embedded whitespace are the "b" and "h"
tags in the "DomainKey-Signature:" header.
valuable suggestions and constructive criticism.