Re: [Nmh-workers] modernizing smtp message submission

[Ken Hornstein]

>Submission on port 587 mandates the use of AUTH.

As others have pointed out, this isn't quite accurate.

>This implies we need
>to default to building with SASL support.

I'm fine with doing that.  But I'm not sure configuration should fail if
SASL isn't available.  I am neutral on that.

>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.

Right, and actually it seems like SASL LOGIN is also common.  Sigh.  Really,
it only makes sense to support SASL if you have the SASL library available.

>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.

I'm fine with 2a.  I do not believe that 2b is the actually the default among
MUAs in my experience, you need to check a box for that.  Also ... when
you say "TLS", do you mean via the "STARTTLS" command, or TLS-at-connect?

I do not think 2d(i) is a good idea; I think that will complicate the code
a lot.

>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 ...

Well, right now the various tls options mandate the use of TLS.  The
same for SASL.  We support SASL mechanism negotiation; part of me thinks
that we shouldn't, and the user should be required to pick a mechanism,
since that's what other MUAs do.

I think the command line options are reasonable.  If you want to extend
mts.conf to support some authentication options, that would also be fine.
We really don't support multiple server except with command-line overrides,
but you can override the security stuff as well.  So I'm not sure we need
a whole lot of extensions there.

However, there are some SASL bits we need work on.  Specifically:

- Do NOT prompt for a password if the SASL mechanism doesn't need one.
- DO prompt for a password if the mechanism needs one, but one hasn't
  been provided yet.
- Prompt for a authentication name (AUTHC) if the mechanism needs one but
  one hasn't been provided yet.  Or should we create a default?
- Make sure we don't allow mechanisms if the channel isn't encrypted (we
  might get the right now, but maybe not).
- Allow the configuration of the authentication name (AUTHC) seperate
  from the authorization name (AUTHZ).

--Ken