[qmail] / RFCQSBMF

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 -0000
      From: MAILER-DAEMON@silverton.berkeley.edu
      To: djb@silverton.berkeley.edu
      Subject: failure notice
      
      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 317 invoked by uid 7); 17 Mar 1996 03:54:38 -0000
      Date: 17 Mar 1996 03:54:38 -0000
      Message-ID: <19960317035438.316.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 VERPs; 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.
Commit	Line	Data
2117e02e MW	1	The qmail-send Bounce Message Format (QSBMF)
	2	D. J. Bernstein, djb@pobox.com
	3	19970201
	4
	5
	6	1. Introduction
	7
	8	When a message transport agent (MTA) finds itself permanently unable
	9	to deliver a mail message, it generates a new message, generally
	10	known as a bounce message, back to the envelope sender.
	11
	12	Bounce messages produced by the qmail-send program display the list
	13	of failed recipient addresses, an explanation for each address, and a
	14	copy of the original message, in a format that is easy for both
	15	humans and programs to read. For example:
	16
	17	Date: 17 Mar 1996 03:54:40 -0000
	18	From: MAILER-DAEMON@silverton.berkeley.edu
	19	To: djb@silverton.berkeley.edu
	20	Subject: failure notice
	21
	22	Hi. This is the qmail-send program at silverton.berkeley.edu.
	23	I'm afraid I wasn't able to deliver your message to the
	24	following addresses. This is a permanent error; I've given up.
	25	Sorry it didn't work out.
	26
	27	<god@heaven.af.mil>:
	28	Sorry, I couldn't find any host by that name.
	29
	30	--- Below this line is a copy of the message.
	31
	32	Return-Path: <djb@silverton.berkeley.edu>
	33	Received: (qmail 317 invoked by uid 7); 17 Mar 1996 03:54:38 -0000
	34	Date: 17 Mar 1996 03:54:38 -0000
	35	Message-ID: <19960317035438.316.qmail@silverton.berkeley.edu>
	36	From: djb@silverton.berkeley.edu (D. J. Bernstein)
	37	To: god@heaven.af.mil
	38	Subject: are you there?
	39
	40	Just checking.
	41
	42	This document defines qmail-send's format for bounce messages.
	43
	44	In this document, a string of 8-bit bytes may be written in two
	45	different forms: as a series of hexadecimal numbers between angle
	46	brackets, or as a sequence of ASCII characters between double quotes.
	47	For example, <68 65 6c 6c 6f 20 77 6f 72 6c 64 21> is a string of
	48	length 12; it is the same as the string "hello world!".
	49
	50
	51	2. Format
	52
	53	A bounce message may be recognized as QSBMF as follows: its body
	54	begins with the characters "Hi. This is the" exactly as shown.
	55
	56	The body of the message has four pieces: an introductory paragraph,
	57	zero or more recipient paragraphs, a break paragraph, and the
	58	original message.
	59
	60	Each paragraph is a series of non-blank lines followed by a single
	61	blank line. The break paragraph begins with the character "-". All
	62	other paragraphs begin with characters other than "-". The break
	63	paragraph is human-readable but provides no interesting information.
	64
65	The introductory paragraph is human-readable. It gives the name and
66	human-comprehensible location of the MTA, but parsers should not
67	attempt to use this information.
68
69	The only type of recipient paragraph described here is a failure
70	paragraph, which begins with the character "<". Paragraphs beginning
71	with other characters are reserved for future extensions.
72
73	The first line of a failure paragraph ends with the characters ">:".
74	Everything between the leading "<" and the trailing ">:" is an
75	(unquoted) Internet mail address.
76
77	A failure paragraph asserts that the MTA was permanently unable to
78	deliver the message to the mail address shown on the first line; the
79	MTA will not attempt further deliveries to that address. The
80	remaining lines of the paragraph give a human-readable description of
81	the reason for failure. Descriptions beginning with <20>, and
82	descriptions containing "#", are reserved for future extensions.
83
84	The envelope sender might not have sent his message to the address
85	shown. There are two reasons for this. First, the MTA may freely
86	replace unprintable characters with "_". Second, the original
87	recipient address may have been an alias for the address shown.
88
89	The original message is an exact copy of the message received by the
90	MTA, including both header and body, preceded by a Return-Path field
91	showing the envelope sender.
92
93
94	3. Comparison with 1892/1894
95
96	RFC 1892 and RFC 1894 together describe a format for delivery status
97	notifications. I have decided not to use that format, because I
98	believe that its complexity will prevent wide implementation and
99	increase the burden on people who manage mailing lists.
100
101	QSBMF is dedicated to failure reports, whereas RFC 1894 allows
102	success reports and deferral reports. Although it would be possible
103	to add deferral paragraphs and success paragraphs to QSBMF, it would
104	be even easier to design separate formats for such notices. I have
105	trouble reading mixed failure/deferral reports.
106
107	QSBMF always returns the entire original message. RFC 1892 allows
108	the MTA to return nothing or to return just the headers; it states
109	``Return of content may be wasteful of network bandwidth.'' However,
110	failure notices are very rare, so the overall loss of bandwidth in
111	this case is insignificant. A much more important issue is storage
112	space: someone who manages a big mailing list does not want to have
113	to store several copies of each message in the form of bounces. The
114	best solution is to have each bounce automatically fed through a
115	program that stores only the critical information. I expect such
116	programs to spring up quickly for QSBMF.
117
118	RFC 1894 provides language-independent error messages, as described
119	by RFC 1893. One can achieve the same results more easily by adding
120	structure to the human-readable failure descriptions, for example
121	with HCMSSC.
122
123	RFC 1894 is able to communicate an ``envelope ID'' and the original
124	envelope recipient address specified by the sender. Unfortunately,
125	this information will almost never be available, since it requires
126	support by every intermediate MTA. All of the applications of this
127	information can be handled reliably, right now, with VERPs; this
128	requires support from the sender's MTA but not from other hosts.
129
130	RFC 1894 includes several pieces of information that might be of
131	human interest but can be seen just as easily from Received lines:
132	the name of the MTA where delivery failed, the name of the previous
133	MTA, timestamps, etc.
134
135	All of these RFC 1894 features have a cost: complexity. A program
136	cannot parse an 1894 report without parsing RFC 822 header fields
137	and understanding quite a bit of MIME. This will limit the
138	availability of parsing software. In the meantime, such reports are
139	annoying to mailing list maintainers, since they are full of
140	uninteresting information and are difficult to parse visually.
141
142
143	4. Security considerations
144
145	Bounce messages may be forged. Never remove someone from a mailing
146	list without sending him a message stating that you are doing so,
147	even if the reason for removal is a series of apparent bounce
148	messages from his address.
149
150	If you send a message along a secret path, you should change the
151	envelope sender address of the message to yourself, so that a bounce
152	will not reveal anything to the original sender. In other words: for
153	secret forwarding, use a mailing list, not a forwarder.
154
155	See RFC 1894 for further discussion of these points.