----- Original Message -----
From: "Frank Ellermann" <nobody(_at_)xyzzy(_dot_)claranet(_dot_)de>
Something like this could be added to the 2821bis examples.
Yes, most definitely, especially in the growing era of "callouts" with
possible long duration applied extensions to SMTP.
That example could also address two immediate questions:
Did you forget a line "S: 150 thanks for your patience",
or do you really switch from 150- to a final 250 ?
Yes, just like it was shown. The real output was shown in the referenced
message in the OPES WG. More below.
If that's a feature and no bug it has to be documented,
it has a "high astonishing factor" on my side.
Minor point, why not 110 or 120 ?
I x5z felt safer? <g>
There was certainly some history behind this idea as I explained in the
entire OPES WG message thread (read the original message in regards to FTP).
I hope this generalization does not bite me. <g>
To begin to answer your questions, the gist of it is this:
This is a "chicken and egg" problem because for a
"Keep Alive" concept where you ANALYZING data,
it may be a situation where you don't really know
what the final response code should be.
When you look at FTP, the final response code for a continuation lines
containing "XXX-" is expected to be XXX. That is per FTP spec and this is
how FTP clients expect it.
So moving to SMTP, one would naturally think the same applied to SMTP
"command line mode" client/server conversations. As Tony Hansen mentioned,
one would had expected the "250-" to be more correct. That natural and fair
presumption is based on having FTP design experience.
As with FTP, where the same response code is expected on each line, RFC 2821
briefly discusses and "eludes" to a similar requirement:
| 4.2.1 Reply Code Severities and Theory
|
| ...
|
| The format for multiline replies requires that every line, except the
| last, begin with the reply code, followed immediately by a hyphen,
| "-" (also known as minus), followed by text. The last line will
| begin with the reply code, followed immediately by <SP>, optionally
| some text, and <CRLF>.
So the above statement 'implies' a persistent reply code for each line.
However, from a technical design standpoint, the persistency "rule" can be
broken
with the following statement:
| In many cases the SMTP client then simply needs to search for a line
| beginning with the reply code followed by <SP> or <CRLF> and ignore
| all preceding lines. In a few cases, there is important data for the
| client in the reply "text". The client will be able to identify
| these cases from the current context.
This makes it possible for SMTP clients reading continuation response codes
do not have to match the final response code and based on my R&D, this is
indeed the case. Note, I tested only the OUTLOOK MTA.
Unlike FTP, this is actually fantastic and what you want in SMTP. It
resolves the 'chicken and egg' problem of not knowing what should be the
final response code as your sink is analyzing the SMTP DATA payload.
John, can tell you more and maybe there is some historical perspective and
it was intentional left open for interpretation so that cients are not
locked in to using a persistent reply code.
Yes, I think it is important to discuss this and allow for a Keep Alive
Concept or usage with some recommendation for limitations. I talked about
this a many times. It is going to be required more and more in the future
(Paul is an example) with the growing era of "callouts", "shims," "sinks,"
or "hooks" or whatever which way you want to call it. You have the Sieve
People also thinking do add more overhead related functionality. Across the
board, you got new pressures to do more state machine delayed analysis. You
got CBVs being used more and more either at the MAIL FROM or RCPT TO state
and you got DATA state payload analysis to better support ideas such as
SenderID, DKIM, C/R ideas, etc (and more to come) and if OPES materializes,
SMTP will need to better support all this.
No doubt, it is the future (and natural) direction. We don't want to change
SMTP but you can add functionality and extensions by using call outs.
What we need is a consistent IN/OUT system and consistent reply code system
for all SMTP extended callouts.
Anyway, yes, I think a paragraph or two is needed in 2821bis.
John, do you think a small statement in 4.2.1 indicating the continuation
reply code *SHOULD* or is *NOT REQUIRED* to match the final reply code is
sufficient with a possible reference to a new sections
4.2.x Callout Reply Codes
4.2.x Keep Alive Considerations
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com