On Fri, 2004-12-03 at 10:14, Tony Finch wrote:
> On Fri, 3 Dec 2004, Johannes Berg wrote:
> > On Do, 2004-12-02 at 22:51 +0000, Chris Edwards wrote:
> > >
> > > Would it be theoretically feasible to engineer this and somehow autosense
> > > whether the client is doing tls-on-connect, and if not, provide a regular
> > > SMTP session where ACLs force STARTTLS ?
> >
> > Not within exim. The TLS layer would have to recognise that the client
> > is sending a HELO or EHLO string, and forward that to the upper layer.
> > OpenSSL does something similar with HTTP by then signaling an error
> > condition that basically says: someone tried unencrypted HTTP.
>
> It's a bit more subtle than that.
>
> There's a disagreement between SMTP and SSL over who talks first: in SMTP
> the server starts with a greeting banner, but in SSL the client starts
> straight away with a hello message. (SMTP is in this respect a very
> traditional Internet protocol, whereas SSL is showing its HTTP
> background.) This mismatch shows in practice if you are having problems
> configuring an MUA to use secure SMTP: if you set the port to 465 and the
> software to use STARTTLS, the server will wait for the SSL client hello,
> but the client will wait for the SMTP server banner, and it'll time out
> after a nasty delay. If you get them the other way around Exim will
> complain about a protocol synchronization violation.
>
> If you wanted to get SSL/SMTP auto-negotiation, you'd have to alter the
> SMTP server to delay its banner slightly; if the client says an SSL hello
> inside this delay, assume tls-on-connect, otherwise assume plaintext SMTP.
> This would not be as reliable as the SSL/HTTP autonegotiation because it
> depends on timing rather than protocol message analysis. The greeting
> delay also implies an speed reduction for plaintext clients.
>
> Tony.
Tony thanks for this it explains quite a lot. So in our case having
daemon_smtp_ports = 25 : 465 : 587
tls_on_connect_ports = 465
in the config file is erroneous and should be changed to
daemon_smtp_ports = 25 : 587
tls_on_connect_ports = 465
Our problem comes in advising outlook users, some user of outlook where
the client reports as "Microsoft Office Outlook", work fine on port 465
but give the
protocol violation: synchronization error (input sent without waiting
for greeting)
if they try to use port 587. Other versions of Outlook where the client
reports as "Microsoft Outlook" work fine on port 587 but do not work on
port 465.
Evolution confused me as I did not realise it was smart enough to choose
between starttls and tls_on_connect.
It would seem we are going to have to advise Outlook users to try one
port or the other. Interestingly they all (even outlook express) work on
port 25, I think that is because they all use starttls on port 25 and
only go to tls_on_connect if you change to another port (why do they
that?).
The reason we are doing this is to find a solution for our off campus
AOL users who get their port 25 traffic redirected by AOL.
Cheers
Ron
> --
> f.a.n.finch <dot@???> http://dotat.at/
> MALIN HEBRIDES: NORTHEAST 4 OR 5 INCREASING 6. RAIN LATER. GOOD BECOMING
> MODERATE.
--
Ron McKeating
Senior IT Services Specialist
Internet Services and Software Solutions
Loughborough University
01509 222329
