[Top] [All Lists]

Re: rfc2821bis-01 Issue 18: Usability of 1yz replies

2007-04-10 18:33:49

--On Tuesday, 10 April, 2007 15:22 -0700 Douglas Otis
<dotis(_at_)mail-abuse(_dot_)org> wrote:

On Apr 10, 2007, at 1:46 PM, John C Klensin wrote:

And, for whatever it is worth, the text that starts "The
sender-  SMTP should send..." and ends " does not have
the continue or   abort commands." comes verbatim out of RFC
821.  It has been with   us for a very long time and this is,
at least in my memory, the   first time someone has
identified it as pathologically confusing.    That doesn't
mean you are wrong of course, but it is interesting.

AV filtering and downstream acknowledgment are often essential
to ensure against spoofed bounce exploits that have become all
too common.   As a result, it is normal to enter a situation
where the receiver wishes to issue a "keep-alive" or
"please-wait" to the client.  DKIM does not changing this
situation much if any.  Some ploys may be encumbered.  An
extension is likely the safest alternative.

As soon as one adopts an extension model, we are in agreement.
Whatever I may feel about "keep alive" notions, rather than
quick replies as soon as the data transmission ends, I think an
extension that changes that model and is agreed to by both
server and client is a reasonable approach.

All that I have been objecting to is trying to use 1yz replies
in a continuation context to fake up that "keep alive" behavior.
And I object to it largely because of a sense that too many
clients will impose logic that will ignore those intermediate
responses and time out anyway.  Certainly there is nothing in
821 or any of its successors that suggests restarting a timer
that is waiting on a reply code with each line of the reply that
is received.  Of course, some systems might do that, but it is
nothing on which a server should depend.... again, absent an
extension that is used to get specific agreement from the client
about how the intended "keep alive" is to be expressed and