ietf-smtp
[Top] [All Lists]

Re: Virtual last call on "bounce"

2005-09-11 16:03:51



--On Sunday, 11 September, 2005 09:13 -0700 Dave Crocker
<dhc(_at_)dcrocker(_dot_)net> wrote:

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.


All things being relative, the question is what term to use in
its stead.

I suggest:  return address.

Huh?  The "return address" concept is described, I think and
hope consistently, in 2821 (and 2821bis and 821) as a
"reverse-path" (which is copied at a specified time into the
Return-path, a header field).

"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.

My intent has been that, if it is agreed that "bounce" is an
inappropriate term to be used to contrast with "reject", we then
start a discussion as to what to replace it with and/or whether
to try to erase the distinction (which I think is impossible,
see below).  One way or the other, we need to recheck 2821bis
for consistency of terminology.  But I can't see how "return
address" helps with any of that.

     john

<Prev in Thread] Current Thread [Next in Thread>