John C Klensin wrote:
Note I said per
spec, because there are systems that will put the mail in
delivery motion once that final DATA <CRLF>.<CRLF> is received
and prior to an pending client command.
Which would be a perfectly valid and conforming interpretation
of SMTP. RSET is not specified as causing some action that
occurred earlier to be undone or aborted. FTP was designed to
be somewhat asynchronous; SMTP is not, pipelining
notwithstanding.
Is this wrong?
Yes, I think so.
Well, maybe I stated too much for this gotcha crowd. Our SMTP server
is behaving correctly, but I can certainly see the dividing difference.
If your system is an like many old systems, and our was one of them
for optimization reasons, it will immediately signal a router after a
successful positive reception of DATA <CRLF>.<CRLF> to begin the
delivery process, then absolutely, the MAIL, RCPT and DATA is
immediately "cleared" and effectively, RSET is like NOOP because there
is nothing to be cleared.
However, and we had discussions about this here, to be 100% compliant
with RFC2821 and thus RFC5321, there is a "No QUIT/MAIL" cancellation
requirement per section 4.1.1.10 (QUIT):
If the connection is closed prematurely due to violations
of the above or system or network failure, the server MUST cancel any
pending transaction, but not undo any previously completed
transaction, and generally MUST act as if the command or transaction
in progress had received a temporary error (i.e., a 4yz response).
Under a RFC5321 compliant "No Quit/Mail" cancellation implementation,
after completing the DATA state, the server is waiting for a pending
RSET, MAIL or QUIT command:
QUIT - complete transaction, if any
MAIL - complete transaction, if any
perform a "reset"
RSET - cancel any pending DATA transaction delivery,
perform a "reset"
drop - cancel any pending DATA transaction delivery
We added this support in 2008 as a local policy option
(EnableNoQuitCancel) which will alter your SMTP state flow, your
optimization and now you MUST follow RSET vs QUIT/MAIL correctly.
RSET (after DATA) aborts the transaction, QUIT/MAIL (after DATA) does
not. RSET is not an NOOP at this point.
If you have an old school server (an optimized one), then the mail is
immediately processed for delivery and the cancellation or reset
logics doesn't apply - its was already reset.
Am I still wrong?
The issue with the topic, is that there *could be* "security policy"
related concerns where due to a RSET (after DATA) does not "memorized"
the last DATA rejection state and it may apply.
I agree that SMTP is working properly with the way RSET is defined and
I am not advocating any immediately errata or bis change. But I do
believe it is security insight for SMTP in the modern age. Just it
down or not, I'm not going to start a Errata, if someone else things
its worthy, go for it. I am just making a note of it.
--
Sincerely
Hector Santos
http://www.santronics.com