[Top] [All Lists]

Re: Changing RFC 5322 guidance about crlf.crlf response delay

2010-08-11 12:36:47

On 8/11/2010 9:53 AM, Murray S. Kucherawy wrote:

-----Original Message-----
From: owner-ietf-smtp(_at_)mail(_dot_)imc(_dot_)org [mailto:owner-ietf-
smtp(_at_)mail(_dot_)imc(_dot_)org] On Behalf Of John C Klensin
Sent: Wednesday, August 11, 2010 8:15 AM
To: dcrocker(_at_)bbiw(_dot_)net; SMTP Interest Group
Subject: Re: Changing RFC 5322 guidance about crlf.crlf response delay

I note, again fwiw, that I've been trying to get various
advocates for a ban (or near-ban) on NDNs to write that separate
document and propose a specific model at regular intervals since
well before 2821 was completed.

I'm new to that particular topic.  Can you explain its motivation or point me 
to a discussion thread that lays it out so I can get some context?

        "Long delays after the<CRLF>.<CRLF>  is received can
        result in timeouts and duplicate messages.  Deferring
        detailed message analysis until after the SMTP
        connection has closed can result in non-delivery
        notifications, possibly sent to incorrect addresses.  A
        receiver-SMTP MUST carefully balance these two
        considerations, i.e., the time required to respond to
        the final<CRLF>.<CRLF>  end of data indicator and the
        desirable goal of rejecting undeliverable or
        unacceptable messages at SMTP time."

I like this text.  I think it reflects current operational realities quite 

Although we can't offer a precise algorithm, because we don't know enough and because network variances make this problematic to do at all, the draft text doesn't provide any assistance beyond "thar be dragons". At the least, we should try to offer tradeoffs, factors, and may even (sudder) a heuristic.

For example, a delay time of up to 2 seconds is probably pretty safe.



  Dave Crocker
  Brandenburg InternetWorking

<Prev in Thread] Current Thread [Next in Thread>