Re: sslio as a STARTTLS wrapper (was Re: sslio error description incomplete/wrong)

On Fri, 7 Jan 2005, Scott Gifford wrote:

> Charlie Brady <[email protected]> writes:
> 
> > On Thu, 6 Jan 2005, Scott Gifford wrote:
> >
> >> Charlie Brady <[email protected]> writes:
> 
> [...]

> > was negotiated. In the fork/exec model which sslio has, this is 
> > necessary/deliberate, since the fork/exec occurs before any data is read 
> > from the network, so, e.g., an environment variable can't be set up for 
> > the the mail daemon describing the SSL negotiation outcome. This prevents, 
> > for instance, the mail daemon from adding a descriptive Received header. 
> 
> With your pipe/socket idea, it would be straightforward to send this
> information back down the pipe, although it would require a more
> complex protocol.

True, but could be as simple as send 'y', then read string until \n.

> SSL may allow renegotiation of parameters, which would be more
> challenging.

In theory yes, but I don't think any of the smtpd+starttls deal with that 
issue already. Nor do I think it's a real issue in practice. OTOH, I don't 
know how much more valuable a received header is than good logging by the 
SSL wrapper.

> Another idea is to have the server exit with a particular exit code
> when SSL was requested; the wrapper would detect this, enable SSL,
> then re-exec the server with the connection, and any SSL settings in
> environment variables.  This is also very simple to implement, and
> enforces the requirement for SMTP that all state is reset after
> STARTTLS.

That's incompatible with the privilege separation. 

It's certainly no better than what I already have, which is that
smtpfront-qmail parses STARTTLS, then execs an SSL wrapped 
smtpfront-qmail.

> I'm not sure whether other protocols require this.

I'd expect they do.

> >> I could probably find some time to help with a project like that,
> >> or at least to test it since the coding should be fairly minimal.
> >
> > Thanks. Have you used Gerrit's ipsvd or Bruce's mailfront?
> 
> I've used mailfront; I've never needed the features of ipsvd, so
> haven't used it.

Functional equivalent to tcpserver, but with a helpful and courteous 
author, and useful license. And now has sslio bundled.

> I'm still in a bit of a brainstorming mood on this, so excuse me if
> this message is a bit scattered.  :)

I'm enjoying the brainstorming.

> P.S.  I can't believe we go through all this crap just to run SMTP+SSL
> on port 25 instead of 465.  :)

True. But people use SMTP+SSL on port 25. And I'm keen to demonstrate that 
big patches to qmail-smtpd aren't the way to provide it. Using something 
other than OpenSSL isn't a bad thing either.

Cheers,

Charlie