Paul Smith <paul(_at_)pscs(_dot_)co(_dot_)uk> wrote:
On Sat, 17 Sep 2005 00:21:10 +0100, John C Klensin
FWIW, at least part of what you are seeing as consensus involves
a number of us sitting back in astonishment that this discussion
has gone on as long and as far as it has.
I agree that there's not consensus in the concept of a 'keep alive'
But, I haven't seen anyone really advocate switching to using accept
and bounce instead of immediate reject - because of the forged email
address issue, and subsequent back scatter.
From my reading of messages here, there need to be several things in
RFC 2821 bis
- a reduction of the recommended timeout values, eg for the post-DATA
timeout to be reduced to 1 minute - IF that is what people want,
again as it *seems* to be here. (Remember, in all this discussion,
no one has requested that the suggested timeouts in 2821 be
increased, so if they were used, 'keep alives' wouldn't be needed).
- a clarification that any checks for RFC 2821 timeouts should be the
time until the final reply code, not continuation reply codes.
- a discussion of accept/bounce later cf reject immediately, and
consequences of using either technique
- a discussion of what to do with time consuming email validation
techniques (eg reject immediately, quickly, and then either
accept/bounce or accept/discard later, depending on trustworthyness
of sender email address).
- a clarification that continuation reply codes should be consistent
with the final reply code.
I haven't seen anything looking like consensus for Paul's suggestion.
In particular, I've seen _very_ little desire to reduce the timeout
after DATA -- instead, IMHO, folks are saying that receiving SMTP
servers that _average_ more than a few seconds per email after DATA
risk running out of resources: thus you shouldn't do this unless you
know what you're doing.
IMHO 2821bis is already too long, and we shouldn't be trying to
turn it into advice-for-all-occasions.
(OTOH, a clarification of what it _means_ to switch reply codes
in midstream might be appropriate -- which would be quite a different
thing than "Don't do it" advice. We shouldn't fool ourselves into
thinking that adding a "Don't do it" will actually stop folks from
John Leslie <john(_at_)jlc(_dot_)net>