[Top] [All Lists]

Re: Keep Alive Response Codes

2005-09-17 01:28:22

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

--On Friday, 16 September, 2005 12:38 +0100 Paul Smith
<paul(_at_)pscs(_dot_)co(_dot_)uk> wrote:

BUT, the consensus here is that you should NOT accept the
message and then send back a bounce later. So, you need to
analyse it at place of entry if possible.

Paul and others,

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.