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