[Top] [All Lists]

Re: RSET command - possible security loophole

2011-05-30 18:46:19


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.


Hector Santos

John C Klensin wrote:

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

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


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

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