Re: wish list

[Raj Mathur <raju@sgi.com>]

Uhm, sorry about the default VM message munging...

Anyhow, I feel that it's more important to have user-level mail
encryption rather than system- or connection-level encryption.  Not
that the latter is not important!  However, the arguments are:

1.  System- and connection-level encryption is a massive load on the
CPU.  If all (or most) of your SMTP connections are encrypted, which
is presumably what we're aiming for, then your CPU will be doing
nothing except handling 20 open SMTP connections at any given time.

2.  The remote system has to support encrypted SMTP, and I don't know
of too many servers around today which do.  I'm willing to be
disabused of this notion in case it isn't true.

3.  Privacy issues still remain with encrypted connections, since
finally the message reposes in a non-encrypted form on the target
machines hard disk.

4.  I haven't read the RFC (OK, you can flame me for that!), but
presumably there's some way of switching between encrypted and
unencrypted sessions between two servers which talk SSL SMTP.  In case 
there isn't, it's a waste of resources to send letters to your Mom
encrypted (unless your Dad's name happens to be Kevin M ;-)

Keeping this in mind, I'd rather focus on user-level security,
i.e. PGP, GnuPG or an equivalent.  There the user has the choice of
whether to encrypt the message or not, and privacy is much much
higher.  In other words, encrypt the payload and let the connection
take care of itself.

Just my 2 paise worth.

Regards,

-- Raju

>>>>> "James" == James H Cloos <cloos@jhcloos.com> writes:

    James> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

>>>>> "John" == John  <john@fiend.securesys.com.au> writes:

    John> I believe there's a standard around the place for SSL'ed
    John> SMTP.

    James> Yes.  That would be rfc2487. The canonical location is:

    James>     <ftp://ftp.isi.edu/in-notes/rfc2487.txt>.

    James> The basic idea is to start a session as normal and then
    James> issue the STARTTLS command (STARTTLS is mentioned in the
    James> EHLO reply of any server that supports it).  At that point
    James> the TLS info is negotiated and the rest of the connection
    James> is secured.

    James> In typical usage, the server's initial announcement, the
    James> EHLO and its reply and the STARTTLS and its reply (and the
    James> TLS negotiation, of course) will be plaintext; everything
    James> else encrypted.

    James> Note that one of the big advantages of this is that it
    James> allows the server the auth and authz clients for such
    James> things as relaying.  Also note that any server advertized
    James> via an MX record MUST NOT require TLS.

    James> - -JimC - -- James H. Cloos, Jr.
    James> <http://www.jhcloos.com/cloos/public_key> 1024D/ED7DAEA6
    James> <cloos@jhcloos.com> E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17
    James> ED7D AEA6

    James> -----BEGIN PGP SIGNATURE----- Version: GnuPG v0.9.7
    James> (GNU/Linux) Comment: For info see http://www.gnupg.org

    James> iD8DBQE3W7qXmXqfF+19rqYRAgi5AKC34Q4yG0HZI0o91WAP0oe3QTgRbQCfc6/b
    James> AdMI4oJPyMSXDFuiTq+Wz5o= =WdHf -----END PGP SIGNATURE-----
-
Securedistros: A common list for all secured Linux distributions
Archive:       http://humbolt.nl.linux.org/lists/