----- Original Message -----
From: "Paul Smith" <paul(_at_)pscs(_dot_)co(_dot_)uk>
Did you forget a line "S: 150 thanks for your patience",
or do you really switch from 150- to a final 250 ?
I'd expect far more SMTP clients not to know what to do with a final '150
'
response than with a final '250 ' response.
The specs clearly say to ignore all continuation lines. The only ones I see
failing with ALL continuaton lines are bulk spammers who are streaming their
junk. We found an old PHP 3.0 sendmail script broken in this area. But I
would not expect the majority of MTA senders will fail in this area. Of
course, that remains to be proven.
(I know our SMTP client doesn't understand 1xx responses, but responses
with a '-' as the 4th character are ignored (as RFC 2821 suggests) except
after EHLO, so it doesn't care about the response code changing)
A few points:
As a SMTP developer, you can only work with whats in front of you:
- What the specs says and if not clear,
- Your experience in other similar state machine protocols, coupled
- with how other products behave.
RFC 2821 section 4.2.1 Reply Code Severities and Theory, has this specific
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.
Now, as a FTP developer as well, this makes you scratch your head alittle
because for FTP, the continuation reply code must match the final response
code. So from a similarity consideration, this conflicts with a common
design consideration for typical command/response code driven state
machines. Only John can tell us if this was intentional or not. POP3 does
not use reply codes (numbers) and from what I can see NNTP has no provision
for continuation reply codes in the POST command.
1xx responses should be followed by another command from the client saying
whether to continue or abort the command, so what you SHOULD have to have
a
1xx response properly, is:
C: DATAWITHCHECK
S: 354
C: lots of stuff
S: 150-please wait
S: 150-please wait
S: 150 Thanks for your patience
C: WASTHATMESSAGEOK
S: 550 message rejected or S: 250 Message OK
True, this would be a natural expectation, but as you are aware, it does not
specifically state that it *must* be the same reply code.
| 1yz Positive Preliminary reply
| The command has been accepted, but the requested action is being
| held in abeyance, pending confirmation of the information in this
| reply. The SMTP client should send another command specifying
| whether to continue or abort the action. Note: unextended SMTP
| does not have any commands that allow this type of reply, and so
| does not have continue or abort commands.
I guess it is assumed to be the same but that is only because the original
usage is to display some lengthy "information" response where the final
response code is already predetermined.
But that isn't going to work. It would have to be an extended SMTP 'DATA'
So, it really shouldn't be a 1yz response.. But - what should it be?
C: DATA
S: 354 Start mail input; end with <CRLF>.<CRLF>
S: 250-Please Wait
S: 250-Please Wait
S: 250-Please Wait
S: 250-Please Wait
S: 550 Message rejected due to content filtering
C: QUIT
Unless I misread you, I disagree. If we were to consider this, my technical
design opinion would be that it should NOT be a 2xx or 5xx, 4xx because that
presents a chicken and egg problem for situation where the client expects
the continuation reply code to be equal to the final reply code.
In other words, if some developer single source his client/server state
machine for SMTP and FTP operations where it does expect the reply code to
be presistent, then it won't work for them nor it will work for you because
you you don't know what the correct feedback should be yet.
The reply code has to be different with the hope they did not follow the ftp
logic and ideally the reply code has to one that provides some level of
appropiate feedback to the client indicating there is some server delay or
"abeyance" as the specification eludes to. For clarity, abeyance implies a
"suspension in time" concept.
So to me, the "1yz-" reply code is more appropiate.
I think RFC 2821 bis should STRESS that multiline responses are possible
....
Why not just hit the direct technical issue on its head? It has to deal
with Timeout and Keep alive concepts anyway. That is what we are dealing
with here. Addressing this will cover all points regarding multiline or
continuation response lines.
Without some sort of backwards compatible 'keep alive' feature like this,
any non trivial content filtering probably will have to be able to fall
back to 'accept and bounce' rather than 'reject', and that is almost
certainly a 'bad thing'
I agree and this alone makes it worth while.
The key consideration is that "callouts" is most definitely the future. It
is here and more and more systems are doing it. I suspect the CBV is the
number #1 call out at this point for SMTP. More and more systems are most
definitely going out to validate the bounce path (simply to determine that
it not bogus and leads to nowhere).
What says John?
How should this be structured to fit within the 2821bis specs?
I suggest a separate, clean, consolidation section talking about:
- Continuation Reply codes vs. Final Reply Code
- Keep Alive, Timeouts and how it may apply to
- Callout concepts, and using
I'll take a stab at it to get the ball rolling.
Suggested Draft Changes/Additions:
4.2.1 Reply Code Severities and Theory
Old Paragraph:
The reply text may be longer than a single line; in these cases the
complete text must be marked so the SMTP client knows when it can
stop reading the reply. This requires a special format to indicate a
multiple line reply.
New Paragraph
There are cases where the reply text may be longer than a
single line or the client should wait for the final response
code due to a server delayed operation. This requires a special
reply format to indicate a multiple line response or
pending final response is to be expected. This is discussed
in detail in 4.3.3 Multiple Response Lines and Timeouts.
New section:
4.3.3 Multiple Command-Reply Lines and Timeouts
There are two situations where multiple reply lines are
desirable:
- The final reply code is pre-determined and
the reply text may be longer than a single line
- The final reply code has not been determined yet and
the server is performing a lengthy backend operation
which may conflict with the SMTP state machine
timeout values defined in section 4.5.3.
This requires a special format to indicate a multiple line reply.
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 FINAL REPLY code, followed immediately by <SP>,
optionally some text, and <CRLF>. As noted above, servers SHOULD
send the <SP> if subsequent text is not sent, but clients MUST
be prepared for it to be omitted.
If the reply code is predetermine, the reply code in continuation lines
SHOULD match the final reply code in the final line.
However, if the server has yet determine the reply code and it will
be performing a lengthy backend operation to obtain the final response
code, then it should use "150-" as the continuation reply line and
display this every X seconds where X is some reasonable amount of
time to keep a client alive. A suggested value for X is 50 seconds.
Examples:
Pre-determined reply code:
S: 250-First line
S: 250-Second line
S: 250-234 text beginning with numbers
S: 250 The last line
Pending Reply Code
S: 354-Starting sending your data
[more than 50 second delay]
S: 150-Processing Data, please wait
[more than 50 second delay]
S: 150-Processing Data, please wait
S: 250 Message Accepted
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.
All clients MUST use the final reply code as the command response value.
It should not expect reply code in continuation lines to be persistent
with the final reply code.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com