I use a hosting provider that isn't keen on customer service, and they recently switched from exim 3.36 to exim 4.20. Exim 3.36 would permit starttls before ehlo, 4.20 doesn't. ssmtp now no longer works for me for tls transfers to my ISP. They haven't been responsive. The RFC isn't clear on whether starttls is permitted before ehlo or not. However, if ssmtp would do ehlo before starttls (as well as after of course to follow the RFC), then I believe it would work correctly with newer versions of exim. Unfortunately, my C skills aren't up to the task of patching ssmtp myself, or I would do so and submit a patch back upstream.
okay... RFC3207 basically says that if the mailserver is private (ie. - not the ISP you are dealing with, a mailserver with no MX record in public DNS) that STARTTLS can be required before the EHLO. If public though... the EHLO should be allowed before STARTTLS. Strictly speaking, exim appears to be doing things fine, and sSMTP is acting like it is communicating to a private mailserver. Looking over ssmtp.c it appears that STARTTLS is always done before EHLO... (as much as 5 minutes of scanning code tells me... unless i missed something, which is possible) This looks like a bug with ssmtp.
I just want to add that while I agree this is a bug in ssmtp, I've switched providers and no longer have a need for this to be fixed.
closing
