At 03:38 14/09/2005, Frank Ellermann wrote:
Hector Santos wrote:
> C: DATA
> S: 354 Start mail input; end with <CRLF>.<CRLF>
> S: 150-Please Wait
> S: 150-Please Wait
> S: 150-Please Wait
> S: 150-Please Wait
> S: 250 Message accepted for delivery. (bytes: 2573)
> C: QUIT
Something like this could be added to the 2821bis examples.
I would agree with that.
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 ?
I'd expect far more SMTP clients not to know what to do with a final '150 '
response than with a final '250 ' response.
(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)
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
But that isn't going to work. It would have to be an extended SMTP 'DATA'
command to have a legitimate 1xx response after it (see RFC 2821 4.2.1
section on 1yz replies), so all clients would need to be changed to support
that extension. This isn't acceptable.
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
could be said to be as bad - the response is changing from 2xx to 5xx, and
using 4xx or 5xx as the intermediate responses has the same problem if the
final response is a 2xx response
I think RFC 2821 bis should STRESS that multiline responses are possible
after any command (currently RFC 2821 section 4.2 says 'Only the EHLO, EXPN
and HELP commands are expected to result in multiline replies in normal
circumstances, however multiline replies are allowed for any command' -
some people will have stopped reading that after the first few
words "Only the EHLO, EXPN and HELP commands are expected to result in
multiline replies....", and their brains would have overheated at that
point and they won't have read any further - you know it will have happened...)
RFC 2821 bis should also (IMHO) recommend (rather than just "suggest") the
behaviour described at the end of section 4.2.1:
"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."
It should also say (IMHO) that the reply codes on the preceding lines
should be deemed to have been overridden by the final reply code in case
they are different ( unless the specification of the particular command
being replied to says otherwise).
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'
Paul VPOP3 - Internet Email Server/Gateway
support(_at_)pscs(_dot_)co(_dot_)uk http://www.pscs.co.uk/