My take on this:
I think the client should be aware that most, if not all, servers
expect a 2nd pass of EHLO, but I also believe the client should not
presume server features would be the same under TLS and NON-TLS sessions.
For example, the use case where the private or even public server
allows a stronger AUTH for non TLS sessions and allows weaker AUTH
under TLS:
S: 220 blah blah blah
C: EHLO client-domain.com
S: 250-server-domain.com
S: 250 AUTH CRAM-MD5 OTHER
S: 250 STARTTLS
C: MAIL FROM: <xxxxxxx>
S: 530 Must issue a STARTTLS or AUTH command first
...
Note: both RFC 2487 (TLS) and RFC 2554 (AUTH) use 530 for an
enforcement requirement. So here, if it client support CRAM or DIGEST
it can continue with AUTH CRAM-MD5 or AUTH OTHER. But if it does not
support these stronger AUTH, and does support TLS, it can continue
with a STARTLS:
...
C: STARTTLS
S: 220 Go ahead
C & S: <TLS negotiation>
C: MAIL FROM: <xxxxxxx>
S: 530 AUTH command first
C: EHLO client-domain.com
S: 250-server-domain.com
S: 250 AUTH LOGIN
S: 250 AUTH-LOGIN
S: AUTH LOGIN
S: 235 Authentication successful.
The point is, the client MUST be aware of this possibility and should
always (MUST) issue an EHLO after TLS is established.
The idea of public vs private and level of authentication is discussed
in 2487 and this is where the 4.2 statement:
The client SHOULD send an EHLO command as the
first command after a successful TLS negotiation.
is "forgetful" of its other key points. So it should of been
something like:
For a SMTP server that is privately referenced, the client
MUST issue the EHLO command after a successful TLS negotiation
to determine if there are any changes in AUTH methods, such
as the strength of the authentication.
If the server is the publicly reference, the client SHOULD
send an EHLO command as the first command after a successful
TLS negotiation, however, it is highly recommended it reissues
the EHLO in all cases.
The client SHOULD not degrade from EHLO to HELO.
My take.
--
Sincerely
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
Tony Hansen wrote:
Ahhh, there's where the difference in interpretation lays. One
interpretation is that the remote side is required to forget the value
that was passed with the original EHLO command. Another interpretation
is that it further must forget that an EHLO command was issued at all.
I guess I can see either interpretation of the STARTTLS spec.
Tony Hansen
tony(_at_)att(_dot_)com
Tony Finch wrote:
On Tue, 27 Jan 2009, Paul Smith wrote:
S: 220-main.remotedns.co.uk ESMTP Exim 4.63 #1 Mon, 26 Jan 2009 18:25:48 +0000
S: 220-We do not authorize the use of this system to transport unsolicited,
S: 220 and/or bulk e-mail.
C: EHLO vpop3.company.co.uk
S: 250-main.remotedns.co.uk Hello vpop3.company.co.uk [IP address]
S: 250-SIZE 52428800
S: 250-PIPELINING
S: 250-AUTH PLAIN LOGIN
S: 250-STARTTLS
S: 250 HELP
C: STARTTLS
S: 220 TLS go ahead
<TLS negotiation>
C: MAIL FROM:<user(_at_)company(_dot_)co(_dot_)uk>
S: 550 HELO required before MAIL
(It happens with a few domains, all of which seem to be using Exim (4.63
or 4.69))
This is a common but (obviously) non-standard anti-spam check. Practically
the only software that doesn't issue HELO or EHLO is malware so the check
has a negligible false positive rate. (Malware doesn't use TLS either, so
your bug is triggering a slightly over-broad check.)
It certainly looks as if it has forgotten the fact of the EHLO command
once the STARTTLS has happened.
As it is required to do.
Tony.