Re: [Exim] TLS on a port other than 25

Top Page
Delete this message
Reply to this message
Author: James P. Roberts
Date:  
To: Mark Edwards
CC: exim-users
Subject: Re: [Exim] TLS on a port other than 25
> >
> > I suspect the clients are behaving differently....
>
> Well, what happens is I can connect either with STARTTLS or not to

port 25,
> and everything is logged normally. I can connect normally to port 26

and it
> is logged, but if I try to use STARTTLS on any port other than 25, the
> connection times out and nothing ever gets logged.
>
> My conclusion is that a STARTTLS connection on a port other than 25

(I've
> also tried 587) isn't even making it to Exim. The real question is

where is
> it failing? Is it failing at the client (doubtful, because I don't

think
> the client would time-out, and I've tried on two different clients on

two
> different OS's) or is the connection being intercepted somewhere

before it
> gets to Exim?
>
> Has anyone seen a STARTTLS connection on a port other than 25 actually

work?
>


Not with a M$ client, no. Because they do not use STARTTLS on any port
other than 25, as I posted earlier. (Been there, done this). Quite
simply, unless the server is expecting SMTPS (not STARTTLS), the
client's initial request looks like gobbledygook, and it will get
ignored, resulting in a timeout. And, of course, the M$ error message
makes it look like the problem is on the server's end, when it is in
fact a stupid M$ client problem. So, to get encryption working on any
port other than 25, either use a non M$ client, or set up xinetd with
something that can handle the client's connection (such as Stunnel,
which is free and open-source, by the way). As I already said.

What you want simply will NOT work with a Microsoft client, because it
is stupid software that ASSUMES you must not want to use STARTTLS if you
are connecting to a port other than 25. Instead, it reverts to smtps,
WITHOUT bothering to tell you about it.
I am just trying to share my own horrible experience with this exact
same problem.

Jim Roberts
Punster Productions, Inc.