I will have to agree with Tony here, in particularly to point 1 and 3.
We don't have any assurance the client will react as the server desires
using such "rare" immediate response codes that are different from the final
response codes and/or that the "broken" clients even expects them. Since
the natural design assumption is that they are persistent and I think we
need to stick with this with the current specification.
Therefore, I think possible 3 items for 2821bis:
1) Clarify intermediate REPLY codes [SHOULD?/MUST?] be persistent with
the final REPLY code. See paragraph in question about ignoring all
continuation lines.
2) A discussion dealing with the increasing need to address
PAYLOAD analysis at the SMTP level (DATA stage) to satisfy
a slew of new protocols and/or address bounce attacks.
3) Maybe suggest a new "Heartbeat" or "Keep alive" REPLY CODE
or leave this for an SMTP extension.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
----- Original Message -----
From: "Tony Finch" <dot(_at_)dotat(_dot_)at>
To: "Paul Smith" <paul(_at_)pscs(_dot_)co(_dot_)uk>
Cc: "Frank Ellermann" <nobody(_at_)xyzzy(_dot_)claranet(_dot_)de>;
<ietf-smtp(_at_)imc(_dot_)org>
Sent: Thursday, September 15, 2005 6:52 AM
Subject: Re: slow email validation problems (was reject vs bounce)
On Wed, 14 Sep 2005, Paul Smith wrote:
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).
That's a very bad idea for a number of reasons.
(1) There is code out there which takes the response code from the first
line, not the last.
(2) Servers often provide multil;ine responses with important information
in the text on all lines, e.g. to explain a 550 rejection.
(3) The assumption up to now has been that reply codes must be consistent;
this is not something that you can change at such a late stage.
(4) If you want to change SMTP or add features, write a service extension.
IMO the informal suggestion in the last paragraph of 4.2.1 should be
removed. It was originally from a non-normative appendix in 821, and
probably should not have been promoted to the body of the specification
without closer scrutiny.
Tony.
--
f.a.n.finch <dot(_at_)dotat(_dot_)at> http://dotat.at/
BISCAY: WEST 5 OR 6 BECOMING VARIABLE 3 OR 4. SHOWERS AT FIRST. MODERATE
OR
GOOD.