In RFC5321, section 4.1.1.5 it says:
4.1.1.5. 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: 64.187.117.40:27208 (unknown)
16:19:40 S: 220 winserver.com Wildcat! ESMTP Server v6.3.453.5 ready
16:19:40 C: EHLO mail.greatsunshines.com
16:19:40 S: 250-winserver.com, Pleased to meet you.
16:19:40 S: 250-SIZE 10240000
16:19:40 S: 250-ETRN
16:19:40 S: 250-AUTH CRAM-MD5 LOGIN PLAIN
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.
Comments?
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.
--
Sincerely
Hector Santos
http://www.santronics.com