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.