[Top] [All Lists]

RSET command - possible security loophole

2011-05-30 16:29:45

In RFC5321, section it says:  RESET (RSET)

   This command specifies that the current mail transaction will be
   aborted.  Any stored sender, recipients, and mail data MUST be
   discarded, and all buffers and state tables cleared.

I have observed a "security loophole" where by spammers are increasingly using RSET to avoid new local policy-based anti-spam technologies such as DNSRBL, SPF, Greylisting, etc, at the SMTP level and this is because the transaction "state" tables during the same session were cleared. Since these external functional generally just has one output, false/true and/or reply code (45x/55x), the additional process insight to retain the rejection state is not available.

It seems we need an exception clause for the RSET command to close this "security" loophole or clarification if the above MUST apples to the state tables.

Here is an example of such a transaction:

Wildcat! SMTP Server v6.3.453.5
SMTP log started at Mon, 30 May 2011  16:19:40
Connection Time: 20110530 16:19:40  cid: 000079BD tid: 000008FC
Client IP: (unknown)
16:19:40 S: 220 Wildcat! ESMTP Server v6.3.453.5 ready
16:19:40 C: EHLO
16:19:40 S:, Pleased to meet you.
16:19:40 S: 250-SIZE 10240000
16:19:40 S: 250-ETRN
16:19:40 S: 250-AUTH=LOGIN
16:19:40 S: 250 HELP
16:19:40 C: MAIL FROM:<StudentAid(_at_)greatsunshines(_dot_)com>
16:19:40 S: 250 <StudentAid(_at_)greatsunshines(_dot_)com>... Sender validation pending.
16:19:41 C: RCPT TO:<sysop(_at_)santronics(_dot_)com>
16:19:41 ** WCX Process: wcsap  ret: PASS
16:19:41 S: 250 <sysop(_at_)santronics(_dot_)com>... Recipient ok
16:19:41 C: DATA
16:19:41 S: 354 Start mail input; end with <CRLF>.<CRLF>
16:19:41 ** end of data received. (bytes: 2902) (141.7 K/s)
16:19:42 ** WCX Process: SmtpFilterHookLoader  ret: FAIL=451
16:19:42 S: 451 Please try again later (TempFail)
16:19:42 C: RSET
16:19:42 S: 250 Reset State #1
16:19:42 C: MAIL FROM:<NewWindows(_at_)greatsunshines(_dot_)com>
16:19:42 S: 250 <NewWindows(_at_)greatsunshines(_dot_)com>... Sender validation pending.
16:19:42 C: RCPT TO:<sysop(_at_)santronics(_dot_)com>
16:19:42 ** WCX Process: wcsap  ret: PASS
16:19:42 S: 250 <sysop(_at_)santronics(_dot_)com>... Recipient ok
16:19:42 C: DATA
16:19:42 S: 354 Start mail input; end with <CRLF>.<CRLF>
16:19:42 ** end of data received. (bytes: 11638) (141.0 K/s)
16:19:46 ** WCX Process: SmtpFilterHookLoader  ret: PASS
16:19:46 S: 250 Message received for delivery. (bytes: 11638)
16:19:46 C: QUIT
16:19:46 ** message copied to router prespool
16:19:46 ** Router signaled to begin handling new message
16:19:46 S: 221 closing connection
16:19:46 ** Completed

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.

Now, this is an implementation issue since our greylist script does have the information, such as session client id (CID: 000079BD) passed to both DATA filter script calls (SmtpFilterHookLoader) and the greylist filter should not have allowed a second attempt for the same session to bypass its initial temp fail result.

But in general, for RFC5321, this "security" information should be conveyed in regards to the RSET command. Perhaps:

Any stored sender, recipients, and mail data MUST be discarded, and all
   buffers and state tables cleared which the possible exception of local
   policy transactional session security state information that may need
   to be retained for the current SMTP session.


If anything, this might be good info for other operators and implementors of greylist and other SMTP level filtering methods to check to see if spammers are using RSET to get pass an initial reject.


Hector Santos