ietf-smtp
[Top] [All Lists]

Re: rfc2821bis-01 Issue 14 Continuation of 222 greeting and Issue 15 syntax for multiline replies

2007-04-09 05:33:36

Thanks Frank,

I just took a quick look at the current 2821bis and didn't see anything in section 4.2. "SMTP Replies" related to the following. Please tell me if you think is it important.

1) Must all the codes in the multiline response be the same?

2) Which is the final return code, the first or the last?

Examples:

 221-Blah blah blah
 221-Blah blah blah
 221-Blah blah blah
 220 Blah blah blah

The next example was a test for a proof of concept regarding potential client time outs issues in new environments where the server is performing extended backend processing, i.e., OPES for SMTP.

 354 Please Start sending....
 150-Please Wait...
 150-Please Wait...
 451 Sorry, Rejected, try again later

The clients I tested will use the last response-code as the server response code but more important it resolve the timeout issue.

Here is an old thread about this:

http://www.imc.org/ietf-openproxy/mail-archive/msg03282.html

--
HLS

Frank Ellermann wrote:
Hector Santos wrote:
Are you saying that you have included a statement in the new
text that suggest implementations intentionally use MULTI-LINE
welcomes in order to trap bad guys?

Nope, that was only a minor point in the discussion.  The new
ABNF will be obvious, something in the direction of Tony's ABNF,
maybe using "=/" instead of only "/" for the alternative -- the
latter didn't have the "strongly advised" grouping -- and using
a defined <Reply-text> instead of an undefined <text> unrelated
to the 2822 <text>.

The old prose could be interpreted as if it limits multi-line to
command replies, so probably John would now just enumerate known
cases where multi-line is okay explictitly adding the "greeting".

In theory John could add a note that clients are considered as
broken if they don't accept multi-line greeting, but IMO that's
unnecessary, the new ABNF is obvious.  It's no convoluted case
of "MUST/SHOULD accept" plus "MUST/SHOULD not generate", where
an explicit explanation in the prose would be required.

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