THE WORDS BEHIND THE DIAGRAMS
A shared glossary for Visual RFC. Look up an acronym, a signature tag or an unfamiliar word. In the lessons, hover, focus or tap an underlined term for a quick explanation.
28 terms
Explore bh=, h=, b= and l= in the DKIM lesson ↗
Try a shorter word or clear the search to see every definition.
The signature over the selected headers and the DKIM signature header.
The signer creates b= with its private key. The receiver checks it with the DNS public key. Its input includes bh= and the other DKIM tags, with b= treated as empty. It does not encrypt the message.
b=… contains the Base64-encoded signature.Represents binary data using a restricted set of text characters.
It is an encoding, not encryption. DKIM uses it to carry binary digest, signature and key values as text.
Base64 can encode a hash or a signature.A digest of the body bytes covered by this DKIM signature.
The receiver canonicalizes the body, applies l= if present, hashes the covered bytes and compares the result with bh=. The b= signature authenticates this stored digest. A hash alone does not identify the signer.
bh=… contains a Base64-encoded digest.Chooses how headers and body are normalized before hashing or signing.
Header and body modes are independent. Simple preserves more formatting; relaxed normalizes specific whitespace. Neither allows arbitrary word changes.
c=relaxed/simple means relaxed headers and a simple body.Applies precise formatting rules before hashing or signing.
Both sides must apply the same algorithm. In DKIM, header and body rules differ; relaxed rules normalize defined whitespace, not arbitrary changes to content.
Two differently formatted inputs may become identical bytes.The two octets used together as a line ending in these mail examples.
CR is hexadecimal 0D and LF is 0A. The teaching diagrams display ↵ as a label for this two-octet sequence; the marker is not an extra signed character.
CRLF = 0D 0AThe domain taking responsibility for this DKIM signature.
The receiver combines d= and s= to find the public key. This domain can differ from the visible From domain. A DKIM pass alone does not establish their alignment.
d=example.orgAssociates signed message data with a signing domain.
The signer adds a signature. The receiver retrieves a public key from DNS and checks the signed data. A pass does not prove that the message is safe or that a particular person wrote it.
DKIM checks signed data across mail hops.A distributed system for looking up data associated with domain names.
A DNS question names a domain and a record type. The answer can contain addresses, mail-routing data, or TXT data such as a DKIM public-key record.
Look up mail._domainkey.example.org as TXT.A message header field that identifies its stated author or authors.
It is part of the message data, separate from SMTP MAIL FROM. DKIM signs this field’s bytes, but the signing domain can still differ from its author domain.
From: Offers <offers@brand.example>Names the message header fields selected for this signature.
For example, h=from:subject selects From and Subject. A header omitted from this list is outside this signature. Repeated field names follow bottom-up selection rules; the From field must be signed.
h=from:subjectA fixed-size value computed from input data.
A cryptographic hash helps detect changes, but does not by itself establish who supplied the data. DKIM protects its body digest by including bh= in the signed header input.
Different input bytes normally produce different digests.Commands that introduce an SMTP client to the receiving server.
EHLO is the extended greeting and obtains supported extensions. SPF can evaluate the identity given in this greeting.
EHLO mail.example.orgAn optional count of the canonical body octets covered by the hash.
An octet is eight bits. With l=14, only the first 14 octets after body canonicalization enter the hash. Later body content is outside this signature. Without l=, the entire canonical body is covered.
l=14 leaves later body octets unsigned.The SMTP command that supplies the reverse-path address for a transaction.
This envelope sender is used for handling delivery failures and can be empty. It is separate from the From header a reader sees in the message.
MAIL FROM:<sender@example.org>A DNS record that identifies mail servers for a domain.
Its preference value helps order delivery attempts. The record names a host; address records supply that host’s IP addresses.
example.org MX 10 mail.example.orgA group of exactly eight bits.
Protocol lengths often count octets rather than visible characters. A character can require multiple octets in a text encoding such as UTF-8. The ASCII examples in these lessons use one octet per character.
14 octets need not mean 14 characters in every encoding.Carries the public key in a DKIM DNS key record.
For an RSA key, p= contains a Base64-encoded public-key structure. An empty p= revokes the key. The private key stays with the signer.
v=DKIM1; k=rsa; p=…In these signature examples, the secret key used to create a signature.
The signer must keep it protected. Publishing the corresponding public key enables verification without exposing this secret.
Private key → create the signature.In these signature examples, the key a receiver uses to check a signature.
It may be published openly. Knowing it should not let a receiver create the signer’s valid signature. In DKIM, the receiver retrieves it from DNS.
Public key → verify the signature.A document in the RFC series describing Internet protocols, practices, or related work.
Not every RFC is an Internet Standard. Check the document’s category, status, updates and errata when implementing a protocol.
RFC 6376 describes DKIM signatures.An asymmetric cryptographic system with a public and a private key.
These DKIM experiments use RSA signatures with SHA-256. The signer uses a private key; the verifier uses the corresponding public key. Algorithm and key-size guidance is updated by RFC 8301.
The lessons use RSA-2048/SHA-256 signatures.Selects which DNS key to use within the signing domain.
Together, s=mail and d=example.org lead to the TXT lookup mail._domainkey.example.org. Selectors let a domain use different keys.
s=mailA cryptographic hash algorithm with a 256-bit output.
It maps input bytes to a 32-octet digest. The DKIM lessons use it for the body hash and as part of the RSA signature algorithm.
A 32-octet digest can be displayed using Base64.The protocol mail servers use to transfer messages.
An SMTP session negotiates a sender and recipients, then transfers message data. Its envelope identities are separate from the message’s visible header fields.
A relay starts a new SMTP connection.Checks whether the connecting mail server is authorized for an SMTP identity.
A receiver checks the connecting IP address against a policy published by the identity domain. SPF does not directly authenticate the visible From header.
SPF checks an SMTP identity and the connecting IP.In DNS, the interval for which a record may be cached.
A cached record can answer a lookup until its permitted lifetime expires. Other protocols use TTL with different meanings; IPv4 TTL limits packet lifetime and is reduced by routers.
A DNS TTL is expressed in seconds.A DNS record that carries one or more character strings.
Protocols define how they interpret the strings. SPF publishes its policy in TXT records; DKIM publishes public-key records in TXT records at selector names.
TXT is a DNS record type, not an email header.These explanations introduce the terms used in the lessons. Follow the source links for complete protocol requirements and updates.