Glossary

A

Administrative Management Domain (ADMD)

The term Administrative Management Domain, more commonly shortened to ADMD, is used in many standards and related publications related to email. It refers to a single entity operating one or more computers within one or more Internet domain names under said entity's control. One example might be a small company with a single server handling email for that company's single domain. Or an ADMD might refer to a university operating many servers that fulfill different roles, across different networks, all handling email for several different domains used by different groups within the university.

Aggregate Reports

When a Domain Owner publishes a DMARC policy record that includes the rua tag with an email address, this requests that Report Generators send what are known as aggregate reports to the address provided. These reports contain statistics about all messages using the domain that record is published in as part of their RFC5322.From headers. For example, a report might indicate that 10 messages that passed SPF but failed DKIM were received from IP address 1.2.3.4, while 3,000 messages that passed both SPF and DKIM were received from the Domain Owner's email gateway at IP address 4.3.2.1. Busy domains may have very large aggregate reports with thousands and thousands of entries.

Anti-Spam

Referring to something which identifies and/or filters out messages believed to be spam. See also: Spam

Authenticated Received Chain (ARC)

The Authenticated Received Chain, or ARC, protocol allows intermediaries in indirect mail flows, such as mailing lists, virus scanners, and forwarders, to preserve and convey authentication results they observed to the final recipient. This is inspired by the inadvertent blocking of legitimate messages routed through such intermediaries that can occur under certain DMARC policies, because forwarding causes SPF to fail and common alterations to the messages cause the sender's DKIM signatures to no longer verify. More information about ARC can be found at the website http://arc-spec.org.

B

Blacklist

Blacklist is a commonly used term that refers to a collection of computers, domains, email addresses, et cetera that will automatically be blocked whenever they are encountered. See also: whitelist.

Some organizations prefer the term blocklist to avoid any potential issues associated with the terms blacklist and whitelist.

Blocking policy

A common shorthand referring - in an email authentication context - to a DMARC policy that results in unauthorized messages not being allowed to reach the inbox. The policy may be "p=quarantine" or "p=reject" in this case.

C

Cousin Domain

As commonly used a cousin domain is a domain name that is constructed in a way to fool victims into thinking it is a different, specific domain. This can be accomplished by deliberately misspelling the domain - for example, exampl3.com would be a misleading cousin domain for example.com. Fraudsters would register or gain control of exampl3.com and use it to send messages impersonating example.com, and busy or distracted users might not notice the "3" in place of the "e" and assume the message was legitimate, click on a link or open an attachment, and fall victim to the attack. In recent years it is increasingly common to see Unicode characters used to create more convincing cousin domains.

Cryptographic Signature

Often called a digital signature, they make use of certain mathematical techniques to show that the "signed" object has a relationship with the signer, e.g. that an email message was approved by the sender. For DomainKeys or DKIM this would mean a header in the message that can be checked against a key published under the signing domain in the DNS. In a secure messaging system like S/MIME it would be a wrapper for the message that can be verified using the public key certificate of the sender (see [1] for more information).

D

Display Name

The Display Name, also referred to as the "Friendly From," is half of the From: header defined in RFC5322. While the address field of that header is used for routing the message to it's destination, the Display Name is what the recipient's Mail User Agent (MUA) will most often show to the recipient, sometimes without also showing the address field. For this reason fraudsters will often put misleading information in the Display Name, even a complete email address for the domain or brand they wish to impersonate, while using a non-existent domain, or one under their control, in the address field.

Display Name Attack

Traditionally there is no provision to make sure the Display Name and Address Field portions of the From Header refer to the same entity. Bad actors have exploited this by using one address in the Address Field, which the user won't see, and including a completely different address in the Display Name. Because they can use a domain they control in the Address Field, these messages may even pass simple email authentication checks against that domain, while the recipient's email client shows a different domain entirely. This is sometimes referred to as a "Display Name Attack."

DMARC.org and other organizations are developing ways to combat this form of Display Name abuse, and other types of email fraud.

Domain Name System (DNS)

The Domain Name System, commonly referred to as DNS, is a distributed naming system for resources about or part of the Internet, or a private network using the same protocols. It most notably provides the mechanism whereby people only have to remember the names of servers, services, or companies, and the DNS supplies the underlying information needed to make use of those resources over the network. More general information about DNS is available from Wikipedia.

DNS plays a critical part in enabling email authentication systems. In some cases the information about which servers or networks are allowed to send email using a particular domain name is found in DNS. In other cases cryptographic keys used to verify the origin or contents of a message are found in DNS. Details are available in the descriptions of particular authentication systems, but without DNS or something like it, email itself - let alone email authentication - would be much more cumbersome.

Domain Owner

This term refers to the person or organization that currently holds a given Internet domain according to the relevant registrar. Note that the Domain Owner may engage or allow another entity to manage or operate the domain, on their behalf or for their own purposes. Therefore in the context of email, the Domain Owner is not necessarily the same as the ADMD, Message Receiver, or Message Sender for that domain.

Domain-based Message Authentication, Reporting, and Conformance (DMARC)

DMARC is a technical specification that allows Message Senders and Message Receivers to cooperate and thereby better detect when messages don't actually originate from the Internet domain they claim to have been sent from. It does this by allowing the Domain Owner to indicate they are using email authentication on the messages they send, optionally requesting that messages that fail to authenticate be blocked. Message Receivers honor these requests (unless there is a local policy overriding this action), and send reports on all the messages - whether or not they pass email authentication - to the Domain Owner. For more information please review the DMARC Overview. The specification has been published as an Informational document by the IETF as RFC7489.

DomainKeys (DK)

Domain Keys, or DK, is a signature-based Email Authentication technique originally created by Yahoo!. It is documented in RFC4870, but note that it has been superseded by DKIM. More information is available through Wikipedia, or from Yahoo's description (via Archive.org).

DomainKeys Identified Message (DKIM)

Domain Keys Identified Message, or DKIM, is a signature-based [#Email_Authentication|Email Authentication]] technique. It is the result of merging the DomainKeys and Identified Internet Mail specifications, and has been published as a Standards Track document by the IETF as RFC4871 in 2007, and updated as RFC6376 in 2011. More information is available from DKIM.org or Wikipedia.

E

Email Authentication

Email Authentication refers to any technique that helps detect when messages don't actually originate from the Internet domain they claim to have been sent from.

Email Service Provider (ESP)

An Email Service Provider is typically a vendor or service bureau that sends messages on behalf of other organizations. They may use email addresses in Internet domains belonging to their client, or from their own domain(s), in various fields during the SMTP conversation (see RFC5321) or in the message headers (see RFC5322). They are sometimes referred to as Third Party Senders.

F

Final Ultimate Solution to the Spam Problem (FUSSP)

FUSSP is a label sometimes applied to a mechanism whose ability to block spam and/or phishing has been overhyped. It is sometimes used with a tone of gentle amusement, as when an idea tried and found lacking several times is introduced yet again. At other times it has been used as a term of derision when applied to a technique the speaker takes issue with for some reason.

As phishing has become more common, the alternate phrase Final Ultimate Solution for Spam and Phishing has been used.

From Header

The From: Header is defined in RFC5322 and has two parts - the Display Name and the Address Field. The Address Field includes the email address itself, e.g. user@example.com, which is used to determine how to deliver the message. The Display Name or "Friendly From" is intended to hold a more human-readable identifier for the author of the message, such as "Joe User, ABC Dept" might be used. Many email clients only show the Display Name to the user by default.

H

Honey Pot

A Honey Pot is a mailbox intended to collect spam and malware. The mailbox may be created for this purpose, or it may be a pre-existing mailbox taken over after it has ceased being used for some period. The concept is that any mail arriving at the honeypot is automatically suspect, and some operators will assume all received messages are spam. The term spam trap is also used to refer to this type of mailbox.

The policy and timing around taking over mailboxes for this purpose has occasionally caused problems when legitimate senders have different policies on how long to use such email addresses without verifying their owners. A honey pot operator may take over the address a few months after the account has been abandoned, usually after a period where all mail has been rejected so as to inform any lingering legitimate senders that the mailbox is no longer in use.

However a legitimate sender might not send email frequently enough to fall in this period, and thus might not be aware of the abandonment - especially if the rejecting period is only a few months long, which is not uncommon. For a mailing list with a large enough number of these re-purposed mailboxes, this can lead to threatened or actual blacklisting of the sender - regardless of whether the contents of the messages would otherwise be considered legitimate or not.

I

Identifier Alignment

Identifier alignment is a requirement formulated in DMARC that imposes extra conditions on the identifiers used by the DKIM and SPF protocols. Specifically, it requires that any domain identifiers used by the authentication checks these protocols perform must also match or align with the RFC5322.From header (commonly referred to as the "header From:") in order for a "pass" in the other protocols to result in a DMARC "pass.". The alignment may be "strict," meaning an exact match, or "relaxed," allowing a subdomain in one identifier to match the same parent domain in the other.

For a more complete description of identifier alignment, refer to section 3.1 and section 10.4 of RFC7489. For examples using real messages, refer to Appendix B.1 of RFC7489.

Indirect Mailflow

This refers to a mailflow that passes through some form of intermediary - a mailing list, a forwarding service, or similar email service where messages are resent in some form. Depending on the service in question, there may be trivial or significant changes made to the message before it is passed on.

Intermediary

Any operator or service that handles an email message it receives from one ADMD and passes on to another ADMD for delivery. An intermediary may make changes to the message before passing it on, which might range from trivial header manipulation to wholesale reformatting of the message.

L

Local Policy or Local Policy Override

In the context of DMARC, the term Local Policy refers to any internal policy or reason a Message Receiver may have for not enforcing a Blocking Policy published by the Domain Owner for a particular message. It is often indicated as a message like "local policy override" for messages that failed Email Authentication but were never not blocked - for example, because they were received from a mailing list operator that is known to the message receiver.

M

Mailflow

A group of messages that share some feature or characteristic in common. Typical examples would be all messages sent by a company to it's customers, between two companies or departments, from members of a mailing list to each other, or between two individuals.

Malicious Actor

A party that takes actions detrimental to the sender or receiver of messages, an organization, or the Internet at large. It is a fairly broad term because the number of malicious things that can be done with, to, or through email is rather large and difficult to document. A Spammer might be referred to as a Malicious Actor; somebody who phishes, or sends messages that seek to infect or subvert computers and/or networks would definitely fall under this category.

Malicious Content

Anything in a message that will do harm to the Recipient, or the computer and networks they use, may be referred to as Malicious Content. This typically includes the various ways of including viruses and similar content in an email message, but sometimes the term may be used to refer to messages which include a mechanism that might lead the Recipient to take some action that would lead to such content, like a link in the message that leads to a website that delivers code intended to compromise the web browser. Malicious Content is often referred to as malware.

Message Receiver

In the transmission of an email message from one ADMD to another, this is the organization receiving the message on behalf of the intended recipient or end user. The Message Receiver may do this because the intended recipient utilizes mailbox services offered by the Message Receiver (Comcast, GMail, etc), or because they are an employee or member of the organization and have therefore been provided with a mailbox.

Message Sender

In the transmission of an email message from one ADMD to another, this is the organization sending the message on behalf of the Originator or end user.

O

Organizational Domain

DNS provides a hierarchical relationship between Internet domains. The organizational domain concept complements this by identifying the top-level or shortest domain that is still within a given organization. For instance Example Corp operates the domain example.com, and uses the sub-domains mail.example.com and news.products.example.com to send email to their customers. The organizational domain for both of these sub-domains would be example.com, because this is the shortest domain that remains within the same organization as mail.example.com and news.products.example.com. For more information about the organizational domain concept, please refer to Section 3.2 of RFC7489.

Originator

The Originator is the author of a given email message. In different contexts it may refer to the end-user, application, or service that created the message; or to the ADMD providing email services to that party.

P

Policy Override

See Local Policy.

R

Report Generator

A Report Generator is any organization that prepares DMARC aggregate reports or failure reports, and sends them to the address(es) specified in the rua and ruf tags of a domain's DMARC DNS record. This is usually something done by a message receiver, but it could also be a partnered, hosted, or outsourced service.This term is therefore used to be more precise.

Report Processor

This term refers to an organization that receives the DMARC reports (aggregate or forensic) being sent to a given domain from Report Generators across the Internet, and processes them. This can be a function within the organization owning or operating the domain, or a service provided by an external, perhaps commercial entity. In any case, the Report Processor typically receives and processes all DMARC reports for a domain and synthesizes a view of Internet-wide activity using the domain in question, where different trends and threats would be more easily recognized and responded to.

Reputation

In this context Reputation refers to various systems whereby a Message Receiver, or a vendor providing a Reputation Service, may track the past actions of an Originator or Message Sender in order to predict the likelihood that a message their receive from this entity in future may be Spam or contain Malicious Content.

S

Same-Domain Phishing

Same-Domain Phishing refers to phishing campaigns where each message fraudulently uses a domain in the address portion of the RFC5322.From header without permission of the owner. This is one of the most effective types of phishing if it isn't prevented with DMARC or other email authentication methods. By contrast, when a targeted domain implements DMARC and DMARC-enabled recipients can detect the impostors easily. Bad actors are then forced to use a different domain from the one they wish to impersonate, and this mismatch makes it easier for the email filters used by message recipients to detect these messages too.

Sender ID (SID)

Sender-ID is a path-based [#Email_Authentication|Email Authentication]] technique. It was the result of merging the SPF and Microsoft's CallerID specifications, and has been published as an Experimental document by the IETF as RFC4407 in 2006. Sender ID saw limited deployment on the Internet, and is generally not used for new deployments. More information is available from Wikipedia.

Sender Policy Framework (SPF)

Sender Policy Framework, originally Sender Permitted From, is a path-based [#Email_Authentication|Email Authentication]] technique. It was published as a Experimental document by the IETF as RFC4408 in 2006, and updated as a Standards Track document as RFC7408 in 2014. More information is available from OpenSPF.org or Wikipedia.

Snowshoe Attack or Snowshoe Spam

Originally referring to traditional spam campaigns that were sent from many different IP addresses and sending domains spread across different ESPs and/or ISPs (per this Spamhaus article from 2009), this term evolved with spamming tactics by 2014 to also include the notion of a small number of chosen victims along with the other techniques. Like other targeted attacks, this relies on the difficulty of identifying and blocking smaller numbers of messages in a given campaign before most of them reach inboxes.

Spam

Uninvited, unsolicited, and unwelcome email messages are commonly referred to as Spam. They are very often commercial in nature, but the term is used to refer to the fact that these messages are typically sent in large numbers to recipients who never asked for them and do not want them. The history of the term and information about the practice can be found on Wikipedia.

Spam Trap

Spam trap is a commonly used term for a Honey Pot.

Spear Phishing

Spear phishing originally (circa 2005) distinguished between phishing campaigns that targeted broad demographics - people who like celebrity news, or have an account with a given national bank - versus attacks that leveraged some information about a smaller audience, typically involving a single organization. For example, an early spear phishing campaign impersonated the new retirement benefits provider for a company in messages asking that company's employees to disclose their personal information. The key distinction being that it used this knowledge about a limited audience to make the fraudulent message more believable.

By 2015 the term is more often used to refer to highly targeted attacks where a few messages are carefully crafted to exploit known relationships between a very small number of specific individuals tied to an organization. This may mean spoofing messages between the CFO and CEO, or between the financial comptroller and a major external vendor, legal counsel, etc.

Spoofing or Spoofed

In this context, crafting a message that impersonates another party. Most often used to refer to messages that fraudulently misrepresent the sender as a more trustworthy party, but in some cases the term is used to refer to how legitimate third party vendors and Email Service Providers construct messages on behalf of their clients.

T

Targeted Attack

A reasonably general term for any attack that singles out an audience based on knowledge known or inferred about them. This could range from thousands of individuals who all work for a given company, where it can be inferred that they have a relationship with a vendor known to supply services to the organization. Or it could be a very small number of individuals where some additional information is known - for example, top executives and a key supplier or external legal counsel. See also Showshoe Attack, Spear Phishing.

W

Whitelist

Whitelist is a commonly used term that refers to a collection of computers, domains, email addresses, et cetera that will automatically be allowed through whenever they are encountered. See also: whitelist.

Some organizations prefer the term allowlist to avoid any potential issues associated with the terms whitelist and blacklist.