--On Saturday, 10 September, 2005 00:30 +0200 Frank Ellermann
<nobody(_at_)xyzzy(_dot_)claranet(_dot_)de> wrote:
Tony Finch wrote:
2821 uses "bounce" informally but doesn't define it or the
word "reject".
Do we at least have "consensus" that the informal usage of
"bounce" in 2821 does not reflect what most users consider
as "bounce", and in 2821bis we'd be better off if we use
only "reject" or "NDN" ?
And between the lines (not necessarily explicit) I'd like
to have it clear that "accept-on-probation" (because you
can always "bounce" later) is a _bad_ strategy today, and
that "reject a.s.a.p." generally causes less harm.
The old texts always had it clear that "accept" means the
responsibility to deliver (=> report problems as "bounce").
But they did not talk about the default case today, it's
impossible to report any problems as "bounce" to the real
sender if that sender is a spammer forging the MAIL FROM.
RfC 1123 and all later texts were broken wrt this problem,
and 2821bis should acknowledge this: "Yes, it worked as
designed for 821, but 1123 didn't only drop source routes,
it also dropped the [meep] ball while it was at it". And
2821bis as a "ball in play again" standard after 16 years.
While I'm willing to remove the term "bounce" entirely -- as an
editorial matter and as causing more controversy than it is
worth (see earlier "virtual last call" note), I am not persuaded
that there is consensus on deprecating the "accept, process, and
then return (or drop)" model in favor of requiring that
everything be done while the SMTP connection is open. There are
actually some extremely complex tradeoffs in that area. I'd be
quite enthused if someone felt like writing an informational
document that discussed those tradeoffs in a reasonable and
balanced way, and would be inclined (assuming others agreed) to
reference such a document informatively from 2821bis. But,
fwiw, to declare the "deferred determination of deliberability"
model retroactively broken doesn't work for me.
john