Re: RSET command - possible security loophole

John,

I don't think an Errata is necessary unless other people made aware of 
this begin checking their logs and realized its also happening to them 
as well.
I think it is one of those items to write/jot down in a "Keep In Mind" 
todo list so that when a RFC5321bis is ever pursued, we could bring it 
up, debate and address it among other things that might be considered 
for a bis.
The reality is, as I presume you may agree at some level, SMTP today 
is not a pure "stand alone" application. It is highly integrated and 
"feature rich" with security related policy concepts playing a greater 
role.  The flexible reply codes and guidelines to follow it, allow for 
any kind of future state machine to work very well.
We saw the RSET issue for awhile now and it was marked down a 
something to do for our next update. I wasn't quite sure how to best 
address it in general, but specifically from our SMTP level filters 
standpoint, the changes/solution we needed to do was clear - remember. 
That effort was now being done this week and I thought maybe I should 
make a note of it for the group as "food for thought."
As Derek pointed out, there are different transactions with RSET and 
SMTP was designed to handle it independently (correctly IMV).  I don't 
believe its a matter of stupidity or one suggesting a spec not having 
the foresight. Its simple more about current realizations about new 
SMTP integration needs (which I personally believe applies to most, if 
not all, operations) and I just was noting as general as I can, there 
might be additional specific "security" related exceptions to the RSET 
semantics.
--
Sincerely

Hector Santos
http://www.santronics.com


John C Klensin wrote:
> Hector,
>
> Disclaimer: I'm predisposed to avoid changes, especially
> substantive ones, to RFC 5321 if possible; that bias might be
> affecting my opinion.  On the other hand, I might have the same
> opinion without it... and, in this case, I'm pretty sure I do.
>
> It seems to me that you've just made a case for modifications to
> the documents that specify these "policy-based anti-spam
> technologies" and the associated extensions, not to 5321.  The
> extensions could reasonably say that they affect the state table
> and/or modify the correct behavior of RSET.  They could specify
> either that the critical information not be discarded or that
> the SMTP server not continue after a RSET until the
> authentication is repeated (or give the server implementer the
> choice).  They could also contain Security Considerations
> material that discusses this issue.
>
> In that context, the most I can see doing to 5321 would be to
> extend Section 2.2.3 so that the last sentence of the first
> paragraph would read, e.g.,
>
>         "In particular, extensions can change the minimum limits
>         specified in Section 4.5.3, can change the ASCII
>         character set requirement as mentioned above, can
>         introduce some optional modes of message handling, or
>         can change aspects of the state table processing
>         specified in this document."
>
> But I think a modification to 5321 is unnecessary, first because
> the first two sentences of that paragraph read 
>
>         "Extensions that change fairly basic properties of SMTP
>         operation are permitted. The text in other sections of
>         this document must be understood in that context."
>         That ought to be quite clear and does not require us to
> 	list every case.  
>
> Second, doing authentication or authorization tests at the
> beginning of a session and then both discarding the resulting
> information and not requiring that the authentication and
> authorization steps be repeated is, IMO and in technical terms,
> just a dumb implementation.  Per the text quoted above, we've
> told people that, if they use extensions, they have to interpret
> any relevant statements in 5321 in the light of those extensions
> and their effects.  It should be obvious that, if one wants to
> be dependent on some set of security procedures, then executing
> commands without those procedures being in effect is unwise (or
> worse).
>
> To say that even more bluntly, I don't think 5321 needs to
> provide "additional process insight".  No additional words in
> 5321 will prevent implementers who don't feel a need to think
> from their own carelessness and/or stupidity.
>
> If you think that needs to be more clear in the relevant
> extension documents, I recommend that you start generating
> errata.
>
>     best,
>      john
>
>
> --On Monday, May 30, 2011 17:10 -0400 Hector Santos
> <hsantos(_at_)santronics(_dot_)com> wrote:
>
> > 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.
> > ...