There was an error with your request. Make sure you provide a complete email message.

The List-ID Header is described in RFC-2919 § 2 and provides an indentifier for the mailing list that sent a given message.

This identifier is expected to take the form of a fully-qualified domain name.

The List-Unsubscribe Header is described in RFC-2369 § 3.2 and provides a list of URLs that allow a list subscriber to unsubscribe from the mailing list.

The mailto: and https: URL schemes are the preferred mechanisms for unsubscription. There are good arguments for both.

Many ISPs will try and use these URLs when servicing a spam complaint by their user, by attempting to activate the given URLs to terminate the list subscription.

Errors-To is identified as Non-standard, discouraged in RFC-2076 § 3.5.

That said, many senders still use this header in an attempt to cause message bounces to be delivered to the addresses is provides. There are still receive-end tools that interpret this header.

The RFC-5432 § 3.6.2 From header indicates the sender of a message.

With the use of email policy frameworks such as DMARC, RFC-7489, the From header becomes very important.

Messages passing through mailing lists and redirectors may see their From headers rewritten in order to mitigate the effects of such email policies.

The RFC-5322 § 3.6.3 To header lists the recipients of an email message.

Due to forwarding and blind-carbon-copying, the contents of the To header might not match the actual mailbox where the message was delivered to.

The RFC-5322 Date header indicates the exact date in which a message was sent. Ideally, this header is set by the sender itself, although most mail servers append a Date to messages that do not carry one.

Times reported by this tool are automatically converted to UTC and are presented in the RFC-3339 – equivalent to ISO-8601 – format. There is no guarantee that these times are precise not all operators ensure that their clocks remain synchronized.

The RFC-5322 Subject header for an email message. This is an informational field typically added by the sender, to provide the recipient with an indication of contents.

It is common to see mail systems that alter the subject by adding tags to express additional information about a message to its intended recipient.

Tags such as [SPAM] or (External) are frequent examples of this.

The RFC-5322 Message-ID header is a unique identifier for an email message. Typically this identifier will be generated very early in the messge’s lifetime, preserved across its delivery process.

Mail servers are required to generate locally-unique identifiers for each message, which can usually upgraded to globally-unique by appending the mail server host name or similar technique.

Many email systems actually expect the Message-ID to be a trully unique global identifier.

Despite appearances, Message-ID contents are not email addresses.

The RFC-5322 Return-Path header is a trace field that captures the reverse path – in practice, a sender address – for the message.

It is very common for applications requiring per-message tracking to use special addresses providing additional information whenever a bounce message is delivered to this reverse path. BATV and VERP are the two most common techniques that employ this mechanism.

There are many variations of these techniques, where the sender adds various tags to an email address, to distinguish each individual message.

IP Address that sent the SMTP message. In abuse complaints, it is often useful to provide the IP address where the offending traffic originated. Some message formats lack a proper header or control field to pass back this informat

Our software implements a number of heuristics to extract this information as provided by the sender of the report or from the evidence that accomapnies it.

The RFC-5322 Reply-To header is an originator field used to signal the recipient where to send replies to the message.

Automated- and bulk-senders often use this field to redirect replies to their emails to specific mailboxes. Usage by actual persons sending email is less frequent.

An actual email message, headers or fragments that were included in the original message. Abuse complaints will typically include all or part of the offending message, to assist recipients of the report in identifying the source of problem.

In some cases, the included messages are edited to remove personally identifiable data and other tracking identifiers. This is typically done to comply with local policies or regulations regarding protection of personal information.

RFC-5965 provides the Feedback-Type report header to signal the type of incident that the current report applies to IANA maintains the authoritative lists of report types.

The abuse feedback type is probably the most frequently used.

Version is described in RFC-5965 § 3.1 as the actual version of the specification for the ARF report. This is useful as the specification evolve, to allow parsers to better interpret the machine-readable portion of the report.

Although this field is mandatory, we have found many examples of reports sent by large scale operators that either omit the field altogether or include bogus values. In the interest of usefulness, we have modified our tools to cons this field as optional.

The Authentication-Results header is described in RFC-5451 for use in describing the outcome of the authentication process executed by the receiving mail system

ARF messages are used to report authentication failures as per RFC-6591.

As specified in RFC-5965 and RFC-3464, ARF reports and DSNs must contain a human-readable descriptions. The content of this section is presented in its original format.

Due to variability of the activity leading to an ARF reports and DSNs, as well as the idiosincracies of each sender, there is no single, practical specification for this section. It should be expected to contain text that may be useful human analyst reviewing the case.

Useful ARF reports include supporting evidence meant to assist the source to apply relevant mitigation. The Content-Type header as described in RFC-2045 is used for this purpose.

Common values are message/rfc822 and text/rfc822-headers depending on whether full email messages or just its headers are being transmitted.

Useful ARF reports include supporting evidence meant to assist the source to apply relevant mitigation. If included, the content provided as evidence in the ARF report is presented in its original form. This is introduced in RFC-5965.

Note that in many cases, the author of the ARF report might want to obfuscate or remove specific identifying information. There are many reasons for this, including restrictions on personal information handling and specific pri directives.

The Arrival-Date header indicates the date and time at which the message was received by the report sender.

For ARF reports, it is defined in RFC-5965.

For DSN reports, the applicable definition is in RFC-4364 § 2.2.5.

The Delivery-Result header is described in RFC-6591 and is used to convey the final message disposition at the entity that generated the ARF report.

This field is specific to ARF reports used to convey email authentication failures.

The DKIM-Canonicalized-Body header is defined in RFC-6591 and contains the canonicalized body of the message as generated by the verifier, encoded in Base64.

By transmitting a representation of the message body as seen by the verifier, various classes of encoding issues breaking message signature verification can be identified and remedied.

The DKIM-Canonicalized-Header header is defined in RFC-6591 and contains the canonicalized header of the message as generated by the verifier, encoded in Base64.

By transmitting a representation of the headers as seen by the verifier, various classes of encoding issues breaking message signature verification can be identified and remedied.

The Identity-Alignment header is defined in RFC-7489 and contains a comma-separated list of authentication mechanisms that produced an aligned identity.

The keyword none indicates that no mechanism produced an aligned identity. This is likely caused by mismatches betweeen the sender addresses and the authentication mechanisms being used for message transmission.

The Reported-Domain header is defined in RFC-5965. When present, this header lists domain names that the report originator reasonable believes to be related to report.

The mechanism used to assert the relationship between domains and incidents is unspecified. It should generaly be interpreted as a suggestion.

The Reported-URI header is defined in RFC-5965. It is used to indicate one or more URIs that the report sender believe to be related to the report.

The mechanism to establish relationship between URIs and reports is undefined. In general, this should be used as a suggestion by the report sender.

The Reporting-MTA header indicates the name of the MTA reponsible for generating this message.”

Based on context, it can be defined either in RFC-5965 or RFC-3464.

The Source-Port header is defined in RFC-6692 and is used to provide the source port of the TCP connection from which the reported email message originated.

This field is an extension of the Source-IP header.

The Action header is defined in RFC-3464 and indicates the action performed by the report originator.

The values are quite self-explanatory, with delayed and failed being the most prevalent, meaning a message being held in queue while attempting delivery of permanently failed, respectively.

The Last-Attempt-Date header is defined in RFC-3464 § 2.3.7 and provides the time and date of the last attempt to deliver a message, regardless of success.

Times reported by this tool are automatically converted to UTC and are presented in the RFC-3339 – equivalent to ISO-8601 – format. There is no guarantee that these times are precise not all operators ensure that their clocks remain synchronized.

The Status header is defined in RFC-3464 § 2.3.4 and contains the numeric SMTP status code associated with delivery of the reported message to this specific recipient.

The specific status codes are defined in RFC-3463, following a hierarchical structure.

The DSN-Gateway header is defined in RFC-3464 and provides the name of a gateway or MTA that performed translation of a non-Internet delivery status notification to produce the current DSN.

This field is seldom observed in traditional operations, as the bulk of email transmission nowadays happen via SMTP, using fully Internet-connected MTAs.

DSN reports described in RFC-3464 include the original message to be returned to the sender – or a portion. This field shows the Content-Type header as described in RFC-2045 used for purpose.

Common values are message/rfc822 and text/rfc822-headers depending on whether full email messages or just its headers are being transmitted.

The optional per-recipient field X-Actual-Recipient reveals the actual account or mail drop to which an email address maps to.

This field provides insight on aliasing or forwarding that may be at play at the receiving site.