[Top] [All Lists]

Re: RSET command - possible security loophole

2011-05-30 21:14:34

--On Monday, May 30, 2011 20:16 -0400 Hector Santos
<hsantos(_at_)santronics(_dot_)com> wrote:

Glenn Anderson wrote:
At 5:10 pm -0400 30/5/2011, Hector Santos wrote:
So basically, on the first DATA attempt our data filter
returned a  FAIL=451 which was a greylist filter script, the
transaction and state  was cleared with RSET. Then during
the 2nd attempt the client was able  to get by the initial

If you read a bit further in to section it says:
   It is
   effectively equivalent to a NOOP (i.e., it has no effect)
   if issued immediately after EHLO, before EHLO is issued in
   the session, after an end of data indicator has been sent
   and acknowledged, or immediately before a QUIT.

If your server is adhering to the standard, you would still
have the  same problem even if the spammer left out the RSET,
or replaced it with  a NOOP, so this isn't a problem with


Hi Glenn,

Hmmm,  the NOOP is truly a "NO OPeration" command which is a
carry on from the FTP model (which SMTP is based on).  Its an
old school "keep alive" concept to avoid idle timeouts.

Regardless of its origins, questions about when you would want
to use it, how old the school might be, etc., NOOP is specified
in 5321 and means what it says there, not whatever one might
speculatively derive from speculation about is origins.

I would not interpret RSET as not an "NO OPeration" concept -
it will literally reset, delete, purge, etc, stuff already
temporarily recorded by the server for the current session
pending a QUIT or MAIL command to activate the the final
acceptance (per spec) for the mail delivery.

Please read what Glenn wrote and then try reading 5321,
especially Section, again.    There is a "mail
transaction" state, which is initiated by a successful MAIL
command and normally terminated by a successful "DATA" command
(acceptance of the DATA-terminating CRLF.CRLF).  It can also be
terminated, less normally, by QUIT, EHLO, or RSET.  RSET
terminates mail transactions.  Sending RSET when there is no
mail transaction in progress is not harmful (that text is there
partially to prevent someone from responding to a useless RSET
with "503 Command out sequence"), but it is also useless, as
useless as NOOP. 

Contrary to your comment above, RSET does not clear "stuff...
recorded for the current session" because it doesn't clear
session state.  If it did clear ("reset, delete, purge, etc.)
session state, then one would have to send EHLO after RSET to
reestablish client system identification and the extension
offers.  RSET can be followed by MAIL, VRFY, EHLO, or, given
extensions, other commands that might establish either mail
transaction state or some other state.  It is not required to be
followed by EHLO to rebuild the session state.

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