Murray S. Kucherawy wrote:
-----Original Message-----
From: Ned Freed [mailto:ned(_dot_)freed(_at_)mrochek(_dot_)com]
Sent: Tuesday, May 31, 2011 3:29 PM
To: Murray S. Kucherawy
Cc: ietf-smtp(_at_)imc(_dot_)org
Subject: RE: RSET command - possible security loophole
Authentication (AUTH) and session security (STARTTLS) are the obvious examples,
but it is also very common for implementations to support proprietary
mechanisms to allow setting of various session attributes (including but not
limited to the real IP address of the client). Various sorts of proxies are the
usual use-case for this stuff.
Sorry, right, AUTH and STARTTLS of course. My point is that once you hit MAIL
and thus begin message-specific operations rather than connection-specific ones,
I can't think of any SMTP commands that go back and potentially alter session
state in any obvious way that I can think of.
What am I missing?
Well, define "message-specific" because MAIL just gives you the
envelope return path address and we already know that 5321.Mail may
not be same as the 5322.From.
"message-specific" can just be the RFC5322 payload. Maybe you are
pointing out that among the three commands:
MAIL
RCPT
DATA
for a given transaction, we already make persistent reply code
decisions for the same MAIL and RCPT values repeated in all same
session transactions before even getting to the DATA state.
Consider this timing sequence
T1 C: MAIL FROM:<FOO>
** CALL GREYLIST(IP) result: FAIL=450
T2 S: 450 Greylist Rejected, try again later
T3 C: MAIL FROM:<FOO>
** CALL GREYLIST(IP) result: PASS
T4 S: 250 OK
where T3 = T2 + 4 mins and the client waits there for 4 mins assuming
that might be enough of a block time without the the 5 min standard
IDLE timeout. But then again, he can issue a NOOP every minute to
reset the server idle timeout counter, keep the session alive and wait
10 minutes!
I think its "valid" from the SMTP technical standpoint - he did wait
enough to satisfy the block time. Normally, they disconnect and try
later. But it would be sort of dumb to waste resources to wait.
So IMO, the issue is more about trying other transactions after DATA
and how the server, in general, can be informed that new SMTP
transactions would be disabled.
--
Sincerely
Hector Santos
http://www.santronics.com