We've just had a small issue come up wrt STARTTLS and I was wondering if
it was a mistake in RFC 3207, or just me :)
We did a quick patch for someone and added STARTTLS into a new part of
our software in a special build. For speed of releasing the patch, we
didn't make it issue a new EHLO afterwards, based on section 4.2 of RFC 3207
" The client SHOULD send an EHLO command as the
first command after a successful TLS negotiation."
(SHOULD, not MUST). We were planning to add the extra EHLO in before
this went to a general release (we don't need to know about any
extensions other than that STARTTLS, so it's not necessary from our PoV)
. Anyway, 99.9% of the time, it's OK, but they have encountered one
recipient which refuses to accept the message in this case. So, they
seem to be treating the 'SHOULD' as 'MUST'.
Now, earlier in section 4.2, it says "
" The server MUST discard any knowledge
obtained from the client, such as the argument to the EHLO command,
which was not obtained from the TLS negotiation itself"
which I guess is why they are rejecting the message, because (since they
have discarded the fact that we have previously sent EHLO) they are
complaining that we haven't sent EHLO yet.
So, should the 'SHOULD' be a 'MUST' in this RFC, or is the other server
incorrect?
--
Paul Smith
VPOP3 - POP3/SMTP/IMAP4/Webmail Email server for Windows