Tony Finch wrote:
On Sun, 1 Feb 2009, Hector Santos wrote:
I was thinking of 3207 with text similar to:
The secured SMTP client MUST resend the EHLO command and the
secured SMTP server MUST be prepared to issue an 503
for any out of sequence commands by legacy 3207 clients.
What's wrong with the text I suggested?
Upon completion of the TLS handshake, the SMTP protocol is reset to
the initial state (the state in SMTP after a server issues a 220
service ready greeting). The requirement in [RFC5321] that "a client
MUST issue HELO or EHLO before starting a mail transaction" also
applies to this fresh state.
IMO, it is lacking insights regarding legacy servers and clients
potential behavior. See below.
On the other hand, if 3207 is altered to enforce a MUST, then we need to
change our server and in that vain, I reject this 3207 change to a MUST.
This isn't a change to 3207, it's a clarification. This is a requirement
on the client so it isn't strictly necessary for servers to enforce it
(robustness principle and all that).
I like to see "Protocol Consistency." What is expected of the client,
helps define what is expected of the server, and vice versa.
Does your server enforce the
requirement for plaintext connections?
Not sure how that applies. But specifically, its all local policy.
Ok, lets back track and summarize some of this.
Because of the 3207 conflictive semantics, we have come to learn there
are three forms or potential outcomes for behavior:
1) A secured client who literally took the term 3207 SHOULD as an
option and did not expect the secured server to barf when
the secured client did not issue EHLO/EHLO and went straight
to MAIL FROM.
2) A secured server who issued the wrong reply code (550), but
did include correct human response text to an out of
sequence command. This is probably why the OP was able to
find the cause, the human text, but an automated client seeing
550 would think it was a normal server defined return path
address rejection, e.g., maybe SPF? CBV?
3) Due to the 7 year old current wordings in the text, possible
servers, including ours, who will not enforce EHLO/HELO
after TLS is established. We might be the only one, but
who knows without testing all the servers there.
Because of these potentials, I don't think you can generally clarify
and produce generic documents and "cross your fingers" that all
documents will fit and work together to fix the above potentials.
You will need more clarification that will provide specifics to
address situations where they might be compatibility issues.
You covered the general statement. A specific statement is required
to remind legacy servers and clients that out of sequence issues are
possible and appropriate (code) change actions are necessary.
For example, adding to your text:
Upon completion of the TLS handshake, the SMTP protocol is reset to
the initial state (the state in SMTP after a server issues a 220
service ready greeting). The requirement in [RFC5321] that "a
client MUST issue HELO or EHLO before starting a mail transaction"
also applies to this fresh state. Note: Keep in mind that legacy
clients may exist which do not re-issue EHLO/HELO. As required by
SMTP, the server [SHOULD|]MUST issue an out of sequence
negative response. i.e. 503 versus 55x.
If you are not specific, then it is quite possible an "security
argument" can be made such as:
A secured server expects no "errors" in commands sequence and
thus will abort (55x) all unexpected commands during a
secured session.
If you deem this is an appropriate possibility, then that should
probably be stated as well. '
Simply looking for client/server protocol consistency.
--
Sincerely
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com