The qmail-send Bounce Message Format (QSBMF) INTERNET-DRAFT draft-bernstein-qsbmf-02.txt (expires 1 August 1997) This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Status of this memo This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Abstract When a message transport agent (MTA) finds itself permanently unable to deliver a mail message, it generates a new message, generally known as a bounce message, back to the envelope sender. Bounce messages produced by the qmail-send program display the list of failed recipient addresses, an explanation for each address, and a copy of the original message, in a format that is easy for both humans and programs to read. This document defines the format. The qmail-send Bounce Message Format (QSBMF) D. J. Bernstein, djb@pobox.com 19970201 1. Introduction When a message transport agent (MTA) finds itself permanently unable to deliver a mail message, it generates a new message, generally known as a bounce message, back to the envelope sender. Bounce messages produced by the qmail-send program display the list of failed recipient addresses, an explanation for each address, and a copy of the original message, in a format that is easy for both humans and programs to read. For example: Date: 17 Mar 1996 03:54:40 GMT From: MAILER-DAEMON@silverton.berkeley.edu To: djb@silverton.berkeley.edu Hi. This is the qmail-send program at silverton.berkeley.edu. I'm afraid I wasn't able to deliver your message to the following addresses. This is a permanent error; I've given up. Sorry it didn't work out. <god@heaven.af.mil>: Sorry, I couldn't find any host by that name. --- Below this line is a copy of the message. Return-Path: <djb@silverton.berkeley.edu> Received: (qmail-queue invoked by uid 7); 17 Mar 1996 03:54:38 GMT Date: 17 Mar 1996 03:54:38 GMT Message-ID: <19960317035438.26563.qmail@silverton.berkeley.edu> From: djb@silverton.berkeley.edu (D. J. Bernstein) To: god@heaven.af.mil Subject: are you there? Just checking. This document defines qmail-send's format for bounce messages. In this document, a string of 8-bit bytes may be written in two different forms: as a series of hexadecimal numbers between angle brackets, or as a sequence of ASCII characters between double quotes. For example, <68 65 6c 6c 6f 20 77 6f 72 6c 64 21> is a string of length 12; it is the same as the string "hello world!". 2. Format A bounce message may be recognized as QSBMF as follows: its body begins with the characters "Hi. This is the" exactly as shown. The body of the message has four pieces: an introductory paragraph, zero or more recipient paragraphs, a break paragraph, and the original message. Each paragraph is a series of non-blank lines followed by a single blank line. The break paragraph begins with the character "-". All other paragraphs begin with characters other than "-". The break paragraph is human-readable but provides no interesting information. The introductory paragraph is human-readable. It gives the name and human-comprehensible location of the MTA, but parsers should not attempt to use this information. The only type of recipient paragraph described here is a failure paragraph, which begins with the character "<". Paragraphs beginning with other characters are reserved for future extensions. The first line of a failure paragraph ends with the characters ">:". Everything between the leading "<" and the trailing ">:" is an (unquoted) Internet mail address. A failure paragraph asserts that the MTA was permanently unable to deliver the message to the mail address shown on the first line; the MTA will not attempt further deliveries to that address. The remaining lines of the paragraph give a human-readable description of the reason for failure. Descriptions beginning with <20>, and descriptions containing "#", are reserved for future extensions. The envelope sender might not have sent his message to the address shown. There are two reasons for this. First, the MTA may freely replace unprintable characters with "_". Second, the original recipient address may have been an alias for the address shown. The original message is an exact copy of the message received by the MTA, including both header and body, preceded by a Return-Path field showing the envelope sender. 3. Comparison with 1892/1894 RFC 1892 and RFC 1894 together describe a format for delivery status notifications. I have decided not to use that format, because I believe that its complexity will prevent wide implementation and increase the burden on people who manage mailing lists. QSBMF is dedicated to failure reports, whereas RFC 1894 allows success reports and deferral reports. Although it would be possible to add deferral paragraphs and success paragraphs to QSBMF, it would be even easier to design separate formats for such notices. I have trouble reading mixed failure/deferral reports. QSBMF always returns the entire original message. RFC 1892 allows the MTA to return nothing or to return just the headers; it states ``Return of content may be wasteful of network bandwidth.'' However, failure notices are very rare, so the overall loss of bandwidth in this case is insignificant. A much more important issue is storage space: someone who manages a big mailing list does not want to have to store several copies of each message in the form of bounces. The best solution is to have each bounce automatically fed through a program that stores only the critical information. I expect such programs to spring up quickly for QSBMF. RFC 1894 provides language-independent error messages, as described by RFC 1893. One can achieve the same results more easily by adding structure to the human-readable failure descriptions, for example with HCMSSC. RFC 1894 is able to communicate an ``envelope ID'' and the original envelope recipient address specified by the sender. Unfortunately, this information will almost never be available, since it requires support by every intermediate MTA. All of the applications of this information can be handled reliably, right now, with the owner hack; this requires support from the sender's MTA but not from other hosts. RFC 1894 includes several pieces of information that might be of human interest but can be seen just as easily from Received lines: the name of the MTA where delivery failed, the name of the previous MTA, timestamps, etc. All of these RFC 1894 features have a cost: complexity. A program cannot parse an 1894 report without parsing RFC 822 header fields and understanding quite a bit of MIME. This will limit the availability of parsing software. In the meantime, such reports are annoying to mailing list maintainers, since they are full of uninteresting information and are difficult to parse visually. 4. Security considerations Bounce messages may be forged. Never remove someone from a mailing list without sending him a message stating that you are doing so, even if the reason for removal is a series of apparent bounce messages from his address. If you send a message along a secret path, you should change the envelope sender address of the message to yourself, so that a bounce will not reveal anything to the original sender. In other words: for secret forwarding, use a mailing list, not a forwarder. See RFC 1894 for further discussion of these points.