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 differen 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

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.

D

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.

Sometimes the alternate phrase Final Ultimate Solution for Spam and Phishing has been used.

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.

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

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

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

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.

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.

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.