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
