[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Nmh-workers] modernizing smtp message submission

From: Lyndon Nerenberg
Subject: [Nmh-workers] modernizing smtp message submission
Date: Thu, 3 Jul 2014 15:50:39 -0700

While working on the the change to port 587 mail submission I got poking around 
send and post, and came to realize we really need to give the entire SMTP 
submission process an update.

Submission on port 587 mandates the use of AUTH.  This implies we need to 
default to building with SASL support.  That means compiling with the Cyrus 
SASL library.  But that might not be available. As a fallback we could include 
an internal version of SASL PLAIN.  But cleartext passwords are evil, therefore 
we need to build with STARTTLS support.  Etc.

What I'm thinking is:

1) Change configure to enable SASL and TLS by default.

2) Change post's smtp behaviour as follows:

  a) default to port 587
  b) always use TLS if both ends support it
  c) if Cyrus SASL is available, use it.
  d) if not

    i) if TLS is in play, use internal PLAIN if the server supports it, else
    ii) fail

This brings us into line with the behaviour of most other MUAs.

mts.conf (and .mh_profile) are also in need of an overhaul to be able to 
express the permutations of tls/sasl/auth settings and credentials.  I haven't 
given this a lot of thought yet, but I think it's critical for user's be able 
to express enough policy to allow things like mandating TLS encryption 
(regardless of SASL mech), enforce per-server SASL mechs, auth credentials, 
etc.  I don't know that the current config file formats are at all amenable to 
that ...

Anyway, as a first cut I intend to change the configure script to enable 
OpenSSL and Cyrus SASL by default.  For the buildbot slave operators this would 
mean installing the cyrus-sasl2 port.

If anyone has any thoughts about how to express the various security policies 
in the config files, please speak up.  Based on my experiences dealing with 
this in lots of other software (as an end-user) I have a good idea of what 
*doesn't* work, but I'm still far far away from the epiphany of good clean 
configuration syntax for these sorts of policy decisions.


Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

reply via email to

[Prev in Thread] Current Thread [Next in Thread]