Hello,
Have you ever received email from a qmail mailer-daemon? For example:
Here is the reasoning behind the qmail bounce messages:
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.
source
Have you ever received email from a qmail mailer-daemon? For example:
Here is the reasoning behind the qmail bounce messages:
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.
source
