Secure email

Wil Cooley wcooley at nakedape.cc
Sat Jun 2 17:33:06 PDT 2001


Thus spake Thomas 'Balu' Walter:
> +-Wil Cooley-(wcooley at nakedape.cc)-[02.06.01 07:53]:
> > Thus spake Kristoffer Ekelund:
> > > 
> > > Ok, stunnel looks a tad complicated, but I'll look into it. It doesn't
> > > look like a very elegant solution though. Not to me anyway... Are there
> > > really no encrypted protocols for retriveing mail?
> > 
> [...]
> > I made RPMs for stunnel init scripts that'll start stunnel processes
> > listening on the SSL-POP3 and SSL-IMAP ports.  It's better to
> > run stunnel this way, and is one reason I prefer it over sslwrap,
> > because there is less overhead.  You can read about it in the stunnel
> > FAQ: http://www.stunnel.org/faq/run.html#ToC2.  Even though mine
> > are RPMs (and designed to integrate with a Red Hat system), you
> > should be able to find enough in the init scripts to get you going:
> > ftp://ftp.nakedape.cc/pub/packages/contrib/, imapsd and pop3sd.
> 
> Hm - I don't get your reason here... sslwrap can run in inetd and daemon
> mode too, what do you mean by "less overhead"?

Really?  I seem to recall sslwrap could only run through inetd.  Well,
there were other reasons that aren't necessarily important generally,
like the ability to require client-side certs.  I seem to recall that
sslwrap was no longer in development, but I could be mistaken.

Wil
-- 
W. Reilly Cooley                           wcooley at nakedape.cc
Naked Ape Consulting                        http://nakedape.cc
LNXS: Get 0.2.0-devel at http://sourceforge.net/projects/lnxs/
irc.openprojects.net                                     #lnxs

The most costly of all follies is to believe passionately in the palpably
not true.  It is the chief occupation of mankind.
		-- H.L. Mencken
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: not available
URL: <http://lists.linuxfromscratch.org/pipermail/lfs-security/attachments/20010602/4152d498/attachment.sig>


More information about the lfs-security mailing list