John C Klensin wrote (2005-09-11):
The wind seems to be blowing in the direction of removing the
term "bounce" from 2821bis. Different people have different
reasons, but I don't think I've detected anyone who has
claimed that there is value in leaving it in.
[...]
"Bounce" is used in 2821 as a verb. Its use may not be
completely consistent in the current text and an alternative
proposal would be to provide some exact definitions and make it
consistent. But it is now used in the same contexts as
"reject". I think my intent in 2821 was to use "reject" or
"message rejection" to describe "respond to an SMTP command with
a response code and message, where the response code was >= 400"
and "bounce" to describe "formulate and return a mail message
containing a non-delivery report".
The recent discussion, as I understood it, has focused on the
claim that "bounce" is popularly used in some other contexts,
some of them even MUA rather than MTA contexts, and therefore
its use in 2821 was confusing and ambiguous. Some others would
like to prohibit the "delayed notification" (i.e., "reject")
case as much as possible, but that is a question of semantics,
not vocabulary, and has some interesting interactions with
relaying.
[...]
In section 2.4 of 2821bis-01:
| Delivery SMTP systems MAY reject ("bounce") such messages rather
| than deliver them.
s/("bounce")//
In section 3.4 of 2821bis-01:
| o Servers MAY reject or bounce messages when they are not
| deliverable when addressed.
s/or bounce// (551 is a reply code, compare section 3.2 in 821)
In section 3.5.3 of 2821bis-01:
| Similarly, the discussion in Section 3.4 applies to the use of
| reply codes 251 and 551 with VRFY (and EXPN) to indicate
| addresses that are recognized but that would be forwarded or
| bounced were mail received for them.
s/bounced/rejected/ (same 551 as in 3.4)
In section 6.2 of 2821bis-01:
| If they cannot be delivered, and cannot be rejected by the SMTP
| server during the SMTP transaction, they should be "bounced" as
| described above.
The term "bounce" was not introduced in section 6.1, proposed fix:
- If there is a delivery failure after acceptance of a message, the
- receiver-SMTP MUST formulate and mail a notification message.
+ If there is a delivery failure after acceptance of a message, the
+ receiver-SMTP MUST formulate and mail a notification message
+ ("bounce").
The last paragraph of section 6.2 uses the same implicit defintion:
| Conversely, if a message is rejected because it is found to contain
| hostile content (a decision that is outside the scope of an SMTP
| server as defined in this document), rejection ("bounce") messages
| SHOULD NOT be sent unless the receiving site is confident that those
| messages will be usefully delivered.
s/rejection ("bounce") message/non-delivery reports ("bounces")/
After removing all associations of "reject" with "bounce" it would
muddy the water to associate "bounce" with "rejection message", and
the term "non-delivery report" is already introduced in chapter 3.6.
The same "non-delivery report" could replace "notification message"
in 6.1 for a more consistent terminology (maybe a matter of taste),
or use the RFC 821 term "non-delivery notice" in these three cases.
Frank