This document is being written because I, Jeffrey Goldberg, have become fed up with the trouble that some misconfigured or broken Mail Transport Agents (MTAs) are causing to users and managers of Internet mailing lists. The tone of this document may often seem harsh, but it is often better to be clear and direct, then to paper over serious problems.
In this document, I am speaking for myself, although it was written while I worked at the Computer Centre of Cranfield University as part of the email management team, and specifically for managing mailing lists. A version of this document was hosted there for some time.
So please read this document seriously. Email list managers may choose to exclude your site from certain email services as a consequence of misconfiguration. There has been some discussion of creating a "black list" of such sites.
Many sites violate some minor aspects of these standards, but the aspect of the standards that has led to this document being written are things that software systems since 1982 (the date of the standards) have relied on. These are not obscure points of the standards that no one has cared about. Violating the standards does not add or enable some new (non-standard) feature either.
So by connecting your machine to the network you have taken on a responsibility to behave correctly. Passing Email from one host to another is a cooperative activity. Failing to behave correctly makes life harder for other sites. One very important thing to keep in mind is that installing mail transport software from some big and popular software companies does not abdicate you of your responsibility if that software behaves badly on the net. You have the responsibility to get your system acting as a good network citizen or removing yourself from the net. Don't assume that just because a software company is big, that its software behaves correctly. You can't pass the buck.
Contemporary systems make it seem that one can manage a site on the Internet with little more expertise then to be able to drive a graphical interface to configure a mail system. That view is misleading. The software may seem easy to configure, but it appears that it is easy to configure wrongly. You, or someone at your site, still has to understand the basics of the standards of mail transport.
As a site potentially sending out error reports in response to Internet mail, you have a responsibility to either configure your software to work correctly or to replace your software with something that does work correctly. What you use for your local system is your business, but if it talks to the rest of the network, then failure to do so properly is destructive to the operation of the network as a whole.
Mail messages come with many "return addresses". In the actual header of a message, there may be things like "From:", "Reply-To:" and "Sender:". Additionally when two mail systems talk to each other, the sending one provides what is sometimes called a "reverse-path", but is more commonly called an "envelope from". Note that the envelope from is not the same thing as the from line in the mail header. In this document, I will refer to one as the "envelope from" and the other as the "header from".
RFC821 says in section 4.1.1 on the "MAIL" command (which is the one that provides the envelope from)
The [address given by the MAIL command] consists of [...] the sender mailbox. [...] This [address] is used [...] to return non-delivery notices to the sender.
The original wording of the RFC spoke about "lists" and "source routes". In current practice, those can safely be replaced by "address" and "return address" etc, as I have done.
So, if an MTA is going to generate a bounce, it should bounce it to the address in the envelope from if it exists.
What happens if an MTA gets confused and forgets that its an MTA and tries to work from the header information instead of the envelope information.
This is from RFC822, section 4.4.4.
The first point is very clear. Bounces should be sent to the address listed in the "Sender:" field if it exists. Only if it doesn't exist should it defer to the information in the header "From:" field. It should not use the "Reply-To:" field.
4.4.4. AUTOMATIC USE OF FROM / SENDER / REPLY-TOFor systems which automatically generate address lists for replies to messages, the following recommendations are made:
Sometimes, a recipient may actually wish to communicate with the person that initiated the message transfer. In such cases, it is reasonable to use the "Sender" address.
- The "Sender" field mailbox should be sent notices of any problems in transport or delivery of the original messages. If there is no "Sender" field, then the "From" field mailbox should be used.
- The "Sender" field mailbox should NEVER be used automatically, in a recipient's reply message.
- If the "Reply-To" field exists, then the reply should go to the addresses indicated in that field and not to the address(es) indicated in the "From" field.
- If there is a "From" field, but no "Reply-To" field, the reply should be sent to the address(es) indicated in the "From" field.
Note also that normal user level automatic responses should use the "Reply-To:" field, then "From" if Reply-To isn't there, and should avoid "Sender:" for most purposes. But delivery errors should go to the information in "Sender:" if not to the envelope from.
Mail list systems have been explicitly designed since 1982 (and before, since that standards actually codified what was common practice back then) to ensure that both the Sender field and the envelope from contain the address of the list manager. It is the address of the list manager that error reports for addresses on a list should be sent to.
Unfortunately, some MTA software is either completely broken or is misconfigured so that bounces get treated like user-level auto responses going first to a Reply-To and then to a From. Depending on how the mailing list is set up, this can lead to bounce reports going to the entire list or to the person who posted to the list. The situation can persist for quite some time (and leading to a cascading discussion of the bounces) before the list manager even becomes aware that there is a bad address on the list.
Version: $Revision: 1.9 $
Last Modified: $Date: 2001/06/04 23:14:25 $ GMT
First put under revision numbering: March 18, 2001
First established at prior location: Some time in 1997--1998
Author: Jeffrey Goldberg