[Top] [All Lists]

Re: RSET command - possible security loophole

2011-05-30 19:31:18

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

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


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.

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

Is this wrong?


Hector Santos