[Top] [All Lists]

Re: RSET command - possible security loophole

2011-05-30 23:08:47

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
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 (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.


Hector Santos