starred/mailpit

Fork 0

mirror of https://github.com/axllent/mailpit.git synced 2026-04-26 08:45:54 +03:00

[GH-ISSUE #241] TLSRequired option from smtpd not supported #157

New issue

Closed

opened 2026-03-15 12:54:44 +03:00 by kerem · 5 comments

kerem commented

2026-03-15 12:54:44 +03:00

Owner

Originally created by @allesdavid on GitHub (Jan 25, 2024).
Original GitHub issue: https://github.com/axllent/mailpit/issues/241

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.

Originally created by @allesdavid on GitHub (Jan 25, 2024). Original GitHub issue: https://github.com/axllent/mailpit/issues/241 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](https://github.com/mhale/smtpd?tab=readme-ov-file#tls-support). * you can see its usage in smtpd code [there](https://github.com/mhale/smtpd/blob/master/smtpd.go#L100C2-L100C20). * and the expected [error](https://github.com/mhale/smtpd/blob/master/smtpd.go#L376) (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](https://github.com/axllent/mailpit/blob/develop/server/smtpd/smtpd.go#L197)). It would be really nice to have this option (command line/env var) to set the TLSRequired on/off at mailpit level.

kerem closed this issue

2026-03-15 12:54:49 +03:00

kerem commented

2026-03-15 12:54:55 +03:00

Author

Owner

@axllent commented on GitHub (Jan 26, 2024):

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?

@axllent commented on GitHub (Jan 26, 2024): 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?

kerem commented

2026-03-15 12:55:00 +03:00

Author

Owner

@allesdavid commented on GitHub (Jan 26, 2024):

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.

@allesdavid commented on GitHub (Jan 26, 2024): 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. ```

kerem commented

2026-03-15 12:55:05 +03:00

Author

Owner

@axllent commented on GitHub (Jan 27, 2024):

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

@axllent commented on GitHub (Jan 27, 2024): @allesdavid This feature has now been released in [v1.13.1](https://github.com/axllent/mailpit/releases/tag/v1.13.1). Please test and let me know if this works as you expected? Thanks.

kerem commented

2026-03-15 12:55:10 +03:00

Author

Owner

@allesdavid commented on GitHub (Jan 29, 2024):

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

@allesdavid commented on GitHub (Jan 29, 2024): Hi @axllent thank you for your update, we will test it and let you know the results.

kerem commented

2026-03-15 12:55:15 +03:00

Author

Owner

@allesdavid commented on GitHub (Jan 29, 2024):

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.

@allesdavid commented on GitHub (Jan 29, 2024): Hi @axllent, I made some tests and it is working as expected. I used those parameters: ```text 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 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 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.