Proposed patch to enforce STARTTLS before MAIL FROM

Maxim Dounin mdounin at mdounin.ru
Tue Mar 5 18:23:03 UTC 2019


Hello!

On Mon, Mar 04, 2019 at 01:06:58PM -0600, Community Proposed via nginx-devel wrote:

> Hello, in nginx 1.14.2 using a configuration directive of 'starttls only;' and
> 'smtp_auth none;' I noticed this was only applied to the AUTH section of the
> SMTP transaction.  I have written the below to be applied to the MAIL FROM
> section which should be enforced over STARTTLS.  MAIL FROM should occur before
> RCPT TO and DATA to avoid out of sequence errors.  Scenarios where the patch
> changes would be seen in the real world would be for NGINX in front of an MTA
> which is the final destination.  Without enforcing STARTTLS before the MAIL
> FROM the full conversation inclusive of the DATA command can occur in clear
> text during testing.

Not sure it is a good change.

The main goal of "starttls only;" used to be to ensure that 
authenticated clients are using encryption and client credentials 
are not transferred in clear text.  While "smtp_auth none;" is to 
be used on public SMTP servers, and RFC 3207 clearly says that:

   A publicly-referenced SMTP server MUST NOT require use of the
   STARTTLS extension in order to deliver mail locally.  This rule
   prevents the STARTTLS extension from damaging the interoperability of
   the Internet's SMTP infrastructure.

For example, with

   starttls only;
   smtp_auth none plain;

current behaviour is to require SSL/TLS for authentication, but 
allow non-encrypted connections without authentication for mail 
delivery.  This matches RFC 3207 requirements out of the box.

With the suggested change such a configuration would violate the 
above "MUST NOT" clause of RFC 3207.  Moreover, it would be 
impossible to configure nginx with a single listening socket to 
accept only encrypted connections from clients, while accepting 
mail delivery without encryption as required by RFC 3207.

If you want unathenticated clients to use SSL/TLS encryption, a 
better solution might be to enforce this requirement with 
auth_http script.

[...]

-- 
Maxim Dounin
http://mdounin.ru/


More information about the nginx-devel mailing list