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.