TLSRequired option from smtpd not supported

[allesdavid]

Context

We're working on a java application that is not currently enforcing STARTTLS usage for email sending with standard java API.
When we contact our client smtp gateway, which is requiring that the client perform a TLS negotiation before accepting any commands, we received a "530 5.7.0 Must issue a STARTTLS command first", as stated in the RFC 3207 https://www.ietf.org/rfc/rfc3207.txt.

   A SMTP server that is not publicly referenced may choose to require
   that the client perform a TLS negotiation before accepting any
   commands.  In this case, the server SHOULD return the reply code:

   530 Must issue a STARTTLS command first

   to every command other than NOOP, EHLO, STARTTLS, or QUIT.  If the
   client and server are using the ENHANCEDSTATUSCODES ESMTP extension
   [RFC2034], the status code to be returned SHOULD be 5.7.0.

We wanted to use mailpit as an email/SMTP validation tool for our development activities to validate the correct fixing of the application implementation regarding TLS negociation enforcement.
So we run mailpit with following command line: mailpit --smtp-auth-file /path/to/password-file --smtp-tls-cert /path/to/cert.pem --smtp-tls-key /path/to/key.pem

Expected

"530 5.7.0 Must issue a STARTTLS command first" error due to no current TLS negotiation before send command not in the include list of the RFC.

Actual

Mailpit process the request and email is sent without further warning/error.

Analysis

• smtpd has a parameter called TLSRequired as seen here.
• you can see its usage in smtpd code there.
• and the expected error (wich I had with the indus/prod SMTPs) if TLSRquired is not honored.
• but it looks like mailpit has not capability of using it upon smptd instanciation (there).

It would be really nice to have this option (command line/env var) to set the TLSRequired on/off at mailpit level.

[axllent]

Thanks for your very detailed report @allesdavid, that's very helpful! Clearly you have more understanding than I do at this point of how this is expected to work, so maybe you can help clarify some things for me?

Currently Mailpit (more specifically smtpd) requires by default TLS for SMTP logins (--smtp-auth-file) - although the TLS requirement can be optionally disabled using --smtp-auth-allow-insecure. This is obviously not the option you are referring to, as (I'm assuming) the difference is that without TLSRequired a client can optionally (and legally) send some other commands unencrypted if it chose to, just not the actual login part?

If this is correct, are my following assumptions also correct:

To use TLSRequired (I will refer to this option as --smtp-require-tls, although this doesn't exist yet):

• a certificate and key obviously must be provided
• it would obviously conflict with --smtp-auth-allow-insecure - so --smtp-require-tls cannot be combined with --smtp-auth-allow-insecure
• --smtp-require-tls does not require authentication (--smtp-auth-file), ie: it can be used without authentication - it just requires full TLS encryption from the client

Do I understand this all correctly?

[allesdavid]

Hi @axllent and thank you for your answer. Please find below some clarifications:

• a certificate and key obviously must be provided

Yes, certificate and key must be provided

• it would obviously conflict with --smtp-auth-allow-insecure - so --smtp-require-tls cannot be combined with --smtp-auth-allow-insecure

It's not so clear in the RFC but it wouldn't make sense otherwise. So yes, they should be mutually exclusive in my point of view.

• --smtp-require-tls does not require authentication (--smtp-auth-file), ie: it can be used without authentication - it just requires full TLS encryption from the client

Yes, that's right, it's just requiring TLS encryption from the beginning without implying a required authentication following the TLS handshake (from a RFC point of view).
https://www.ietf.org/rfc/rfc3207.txt#:~:text=4.1%20Processing%20After%20the%20STARTTLS%20Command

   After the TLS handshake has been completed, both parties MUST
   immediately decide whether or not to continue based on the
   authentication and privacy achieved.  The SMTP client and server may
   decide to move ahead even if the TLS negotiation ended with no
   authentication and/or no privacy because most SMTP services are
   performed with no authentication and no privacy, but some SMTP
   clients or servers may want to continue only if a particular level of
   authentication and/or privacy was achieved.

[axllent]

@allesdavid This feature has now been released in v1.13.1. Please test and let me know if this works as you expected? Thanks.

[allesdavid]

Hi @axllent thank you for your update, we will test it and let you know the results.

[allesdavid]

Hi @axllent, I made some tests and it is working as expected.
I used those parameters:

    TZ=Europe/Paris
    MP_VERBOSE="true"
    MP_SMTP_TLS_CERT=/certificate/tls.crt
    MP_SMTP_TLS_KEY=/certificate/tls.key
    MP_SMTP_TLS_REQUIRED="true"
    MP_SMTP_AUTH_FILE=/mailpit-smtp-auth-file

Trying to auth without TLS before (v1.10):

	bash-5.0$ telnet <server> 587
	220 mailpit-58c6fcd56-cnz59 Mailpit ESMTP Service ready
	ehlo test
	250-mailpit-58c6fcd56-cnz59 greets test
	250-SIZE 0
	250-STARTTLS
	250-AUTH LOGIN PLAIN
	250 ENHANCEDSTATUSCODES
	AUTH LOGIN
	334 VXNlcm5hbWU6
	<login>
	334 UGFzc3dvcmQ6
	<password>
	235 2.7.0 Authentication successful

Trying to auth without TLS now (v1.13.1):

	bash-5.0$ telnet <server> 587
	220 mailpit-86bbdbfb64-2rgvv Mailpit ESMTP Service ready
	ehlo test
	250-mailpit-86bbdbfb64-2rgvv greets test
	250-SIZE 0
	250-STARTTLS
	250-AUTH LOGIN PLAIN
	250 ENHANCEDSTATUSCODES
	AUTH LOGIN
	530 5.7.0 Must issue a STARTTLS command first

Thank you, Im closing the issue.