155 lines
6.9 KiB
Text
155 lines
6.9 KiB
Text
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.
|