--On Monday, May 30, 2011 19:33 -0400 Hector Santos
<hsantos(_at_)santronics(_dot_)com> wrote:
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.
You could certainly do that. The only advantage of errata is
that they get tracked and not lost. But, again, I don't think
there is a 5321 issue here at all and my suggestion was about
errata to the various extension documents, not to 5321. Even if
5321 were changed to insert an "authenticated state", with RSET
affecting the mail transaction state only, extensions would
still be obligated to explain how much state RSET changed. But,
IMO, we wouldn't want to make that change because there are
actually two different authentication models as far as the state
table is concerned:
S: 220... (connection state)
C: EHLO (starting session state)
...
C: MAIL FROM< (starting mail transaction state)
...
C: <Sending mailbox authentication> (starting type 1
authentication state)
...
and
S: 220... (connection state)
C: EHLO (starting session state)
...
C: <Sending session/ client system authentication> (starting
type 2 authentication state)
...
C: MAIL FROM< (starting mail transaction state)
...
Would one want the same behavior from RSET for both
arrangements? Probably not, although it could be specified
either way. Note that preserving the authentication information
across RSET in the first case would either make
C: EHLO
...
C: MAIL FROM:<foo(_at_)example(_dot_)com>
...
C: RCPT/ DATA/ . / RSET
...
C: MAIL FROM:<bar(_at_)example(_dot_)com>
impossible or actually would create a security hole. On the
other hand, if all that is being done is to authenticate the
sending system and authorize it to send mail (just mail, not
mail on behalf of a particular user), then letting the
authorization carry across mail transactions makes perfect sense.
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.
Yes. But, with the current definition and model that "future
state machine" has to be specified as part of whatever
extensions cause it to be appropriate or necessary. There
isn't any magic that changes the SMTP state machine itself. One
could revise the model itself, but the result wouldn't be 821/
2821/ 5321 SMTP any more.
...
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.
We may just need to agree to disagree here, but, from my point
of view, the SMTP semantics of RSET is quite clear and just
fine. The only relevant SMTP state is "mail transaction" and
that is what RSET resets (it does not, for example, reset the
server capability announcement returned in the reply to EHLO.
If some extension comes along and specified additional state(s),
it is obligated to specify what happens to those states in the
presence of RSET. If it doesn't do so, that spec is defective
(not a problem with 5321 or new semantics for RSET). If it
specifies that RSET discards, e.g., the authentication
information (perhaps by making the extension state part of the
mail transaction state) then my claim is that starting a new
mail transaction without noticing that authentication
information is no longer valid, then I repeat my belief that
would be a dumb (or at least careless) implementation, not much
different in practice from accepting the sequence:
EHLO MAIL RCPT DATA . RSET RCPT
and assuming that the second RCPT could reuse the data from the
first (only) MAIL command despite the RSET. I can imagine
someone trying to justify that on the grounds of robustness, but
the risks are such that I'd think it would be dumb (as well as
fairly clearly non-conformant).
john