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

Página superior
Eliminar este mensaje
Responder a este mensaje
Autor: James P. Roberts
Fecha:  
A: exim-users
Asunto: Re: [Exim] TLS on a port other than 25
> On Mon, 17 Feb 2003, James P. Roberts wrote:
>
> > STARTTLS begins with a normal, clear-text session, during which the
> > server usually advertises support for STARTTLS. After a clear-text
> > "STARTTLS" command from the client, server and client negotiate
> > encryption (everything from here on out looks scrambled), which

persists
> > for the remainder of the connection.
>
> Indeed. That is how TLS is supposed to be used on SMTP connections

(see
> RFC 2487).
>
> > SMTPS was rather more difficult to understand, as the very first

command
> > from the client is not clear-text. It looks garbled to anything

except
> > a server listening specifically for encrypted SMTPS traffic.
>
> SMTPS was a hack that was invented before RFC 2487 came out. I regard
> its use as obsolete, and any software that uses it as "legacy".
>
> > Philip, I know you said it would probably never happen, but I would

like
> > to add this to the Exim Wish List anyway. The ability to handle

both
> > STARTTLS and SMTPS, from a single Exim, on different ports.
>
> I do not like this idea, because it encourages the continued use of
> non-standards. I think there's already enough in Exim - you can use "a
> single Exim" on different ports - but you have to run two daemon
> processes. However, you do not need two different configs.
>
> > It is certainly the case that work-arounds exist
> > (two-daemon solutions). But this is not quite satisfying.
>
> Why are two daemons so unsatisfying?
>
> > I don't think we ever need both STARTTLS and SMTPS on the same port?
>
> That is unimplementable. How does the server know?
>
> Philip
>


Well, I assume that since I can tell, by looking at whether the first
incoming command is "scrambled" or not, if a client is trying to use
SMTPS, that software could be written to make the same determination.
However, as I said, I doubt that would be needed.

I agree that support of legacy software should eventually be phased out.
However, the dominant email client population does not support STARTTLS
on ports other than 25. (Huge, heavy sigh). That is where the fix
should be made, but I wouldn't hold my breath. It is not Open Source
software.

Two daemons is not, by itself, unsatisfying. It is the need to make
changes to files/scripts outside the normal Exim configuration to
achieve the desired results. In one solution, one must mess with the
script that launches the Exim service. In the other solution, one must
mess with xinetd and Stunnel (or equivalent), plus it can impact the
design of the Exim configuration (as a Stunnel connection looks to Exim
like it comes from localhost, rather than remote).

I've almost convinced myself to move away from the Stunnel-based
solution. ;)

I think I was scared by the idea of running multiple instances of Exim,
because I did not know if it was safe to do so. For example, I would
never consider launching both Exim and Sendmail on the same machine,
even if listening on different ports. Is it really is safe to do this,
and the two instances will not interfere with each other? Do they share
the same queue? If so, perhaps one wants to double the time interval
for each one's queue runners, and stagger their start times? I guess I
have a lot of questions. Sorry. Just trying to understand the best way
to handle the situation.

Jim Roberts
Punster Productions, Inc.