On Sat, 3 Jul 2004, Robert Spier wrote: > > Looking into it a bit further - stunnel is the way to go. That way we > > don't have to fiddle with qpsmtpd at all - it just comes for free. > > But then you don't get STARTTLS unless you do some funky magic. You > just get SSL on another port. > > (Or am I missing something?)
No. > Maybe the funky magic isn't so terrible.... but > qpsmtpd->stunnel->qpsmtpd feels wrong. I've recently done the "funky magic" with Bruce Guenter's mailfront. It's not hard at all. Yes, qpsmtpd->stunnel->qpsmtpd "feels wrong" - but it's the way to go. The alternative is doing the SSL in qpsmtpd - which is possible, but IMO not worth the effort. What needs to be done is: - Offer starttls in response to EHLO - parse and validate "starttls" verb. - Return "220 Ready to start TLS" - exec stunnel wrapped around another instance of qpsmtpd There's two features of the second instance of qpsmtpd which need to be modified (e.g. via controlling environment variables). Firstly it shouldn't (or mustn't - I haven't checked) offer STARTTLS. And secondly it must not give a greeting banner before waiting for the client to talk. This second aspect will affect, for instance, the early-talker check. The mailfront patch can be found here: http://lists.untroubled.org/?list=bgware&cmd=showmsg&msgnum=3779 --- Charlie
