Kavi Mailing List Manager Help

Chapter 30. Analyzing Email


This document explains how to analyze information extracted from an email when troubleshooting. It describes the kinds of data that can be found in the email header and message body and what kinds of clues to look for in the various header and message fields.

This document assumes familiarity with terms and concepts introduced in How Email Works.

For instructions on how to view the full header of an email, see Accessing the Full Header for Email Troubleshooting.

Back to top

Reading headers

Full header example

This is a fairly straightforward example of an email sent from a mailing list. Several fields that would normally appear in a header have been omitted so that we can focus on the fields that are most important in troubleshooting. Although certain fields are standard in email headers per the document that defines email standards (RFC 822) there is some variation in the kinds of information that can be added to headers by different mail servers.

Return-Path: <mailinglist@example.org>

Delivered-To: subscriber@example.com

Received: (qmail 12694 invoked from network); 22 May 2004 23:18:10 -0000

Received: from server1.example.com (HELO server2) ( by mailserver.originator_domain.com with mail_application; 22 May 2004 23:18:10 -0000

From: <mailinglist@example.org>

To: <mailinglist@example.org>

Subject: Re: Thread

Date: Wed, 22 May 2004 16:17:19 -0700

Reply-To: bounce_handler@example.org

Header fields you should know about


The 'Return-Path' is contained in the envelope header so it is generally not visible when viewing an email. In this case, the originator is a mailing list whose domain name (listname@domain.tld) is 'mailinglist@example.org'.

This field is important because it contains the fully qualified domain name of the originating sender's email account and cannot be forged. When an email is transferred from the originating MTA to the first receiving MTA, the receiving MTA checks to see whether the hostname that has been provided to it by the originating MTA resolves to a unique Internet address. If it does, then it is a fully qualified domain name and the receiving MTA adds the hostname to the 'Return-Path'. If the hostname does not resolve properly, the receiving MTA adds the originating MTA's IP address instead. Even if the 'From:' and 'Reply-to:' fields do not reveal the address of the originator, this information is available in the 'Return-Path' in the message's envelope header.


The 'Delivered-To' field is contained in the envelope headers so it is generally not visible when viewing an email. This header shows this email was delivered to the mailbox of a subscriber whose email address is 'subscriber@example.com'.

Since email messages generated from mailing lists are addressed to the listname alias, rather than individual subscribers, the 'To:' field in the message header doesn't match the value in the 'Delivered-To' field in the envelope header— so the 'To:' field would contain something like 'listname@example.org' and the 'Delivered-To' field would contain something like bob@marketing.example.com.


A 'Received' field is added to the envelope header for each step of the host-to-host delivery process. The MTA that receives the email adds a 'Received' field with information about the transfer, including the address of the sending MTA, the date and time of the transfer (according to its own 24-hour clock), the length of time it took to process the transfer and the type of email application it used.


This is the message header 'From:' field you see when you view an email message. When you receive an email from another person, the 'From:' field generally contains the person's email address (and name or nickname). When an email is posted to a mailing list, the mailing list software sets the 'From:' field to the listname to protect the private email address of the individual who posted the message.


This is the message header 'To:' field that you see when you view email. In this example, it contains the list address because the message was generated by a mailing list, rather than an individual. If a friend or colleague sent you an email, this field would contain your email address.

This field is similar to the address you'd add to an envelope to send a message through the postal service.


This is the message header 'Subject:' field that you see when you view email.

If this field contains the phrase 'ezmlm warning', the mailing list has encountered a problem delivering the message and sent the sender a warning message. See When the subject is an ezmlm warning for more information.

If you are troubleshooting an email that appears to have vanished and this field is blank, you have found the source of the problem. Spammers frequently send messages with empty 'Subject:' fields, so spam filters check the 'Subject:' field to see if it's empty, and if it is, the message is classified as spam and deleted. Since it would be bad policy—as well as a waste of system resources—to provide a spammer with information about why their broadcast spam message failed, messages deleted by spam filters fail silently. For more information, see Virus Scanning and Spam Blocking.


This is the message header 'Date' field that you see when you view email. It is set by the originating host, so it is not necessarily synchronized with the clocks on other hosts it may have encountered en route.


This field is analogous to the return address on a message you'd send through the postal service. As with hardcopy mail, you must have the addressee's information correctly or the mail may be undeliverable, but you could write anything for the return address and the mail would still be deliverable (if not returnable).

If the message is from another person, their email address will usually appear in this field. If this message is from a mailing list, the 'Reply-To' field will contain the alias for an automated bounce-handler, so that bounced messages are handled properly, rather than being posted to the list and forwarded to all the list subscribers.

Back to top

Looking for clues

There many things that can go wrong with email, and this document only touches on a few of the most common. If you are troubleshooting an email issue and don't see your problem addressed here, Kavi provides extensive documentation on troubleshooting email. See Introduction to Troubleshooting for a list of all available troubleshooting documentation.

Use the Return-Path to trace an email's origin

If an email contains inappropriate content, you may want to determine its true origin rather than assume the perpetrator is the user whose address appears in the 'From:' or 'Reply-To' fields, since these may have been forged. Check the 'Return-Path' to determine the originator's address.

If the email contains spam or malware, there are probably more 'Received' fields than usual because the message route was specified in order to obscure the email's origin.

When email delivery seems slow

When a problem with email delivery is reported, it is seldom a server-related issue. More commonly, the reason delivery seems slow is that the message was sent to a list and routed to a moderation queue. Nonetheless, it does happen occasionally, so if you are troubleshooting this sort of problem, you will probably want to go through the motions of checking the email header in order to eliminate server slowness as a possible cause. See the instructions in the Delivery Path and Times section of the Mail Header tool page help.

For more help resolving this issue, see the troubleshooting flowchart Why Is the Email Slow?.

When the subject is an ezmlm warning

If the 'Subject:' field contains the phrase 'ezmlm warning', the mailing list has encountered a problem delivering the message and sent the sender a warning message. The warning notice will include a copy of the original message plus information about the type of error that occurred and whether the error is permanent (i.e., fatal) or temporary (i.e., transient). For more help troubleshooting this issue, follow the flowchart in What does this message mean?.

Back to top