ietf-smtp
[Top] [All Lists]

Re: Keep Alive Response Codes

2005-09-17 03:18:00

Paul Smith <paul(_at_)pscs(_dot_)co(_dot_)uk> wrote:
On Sat, 17 Sep 2005 00:21:10 +0100, John C Klensin 
<john+smtp(_at_)jck(_dot_)com>  
wrote:

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'
system.

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
trying it.)

--
John Leslie <john(_at_)jlc(_dot_)net>