mailto notifications "should" be sent with a custom TLS override

[wietse-postfix]

RFC 8460 has specific requirements for sending TLSRPT notifications via email. The quote below is from https://datatracker.ietf.org/doc/html/rfc8460#section-3

When sending failure reports via SMTP, Sending MTAs MUST deliver reports despite any TLS-related failures and SHOULD NOT include this SMTP session in the next report.

Consequences:

• If we use the same Postfix MTA to send TLSRPT notifications, then there needs a way to signal that TLS must be optional, and that the SMTP session should not be logged to the TLSRPT library.

Different MTAs my need different solutions for this, and the TLSRPT reporter would need to be configurable to support all of them.

[patrickbenkoetter]

* Wietse Venema ***@***.***>:

RFC 8460 has some specific requirements for sending TLSRPT notifications via email. The quotes below are from https://datatracker.ietf.org/doc/html/rfc8460#section-3 > When sending failure reports via SMTP, Sending MTAs MUST deliver reports despite any TLS-related failures and SHOULD NOT include this SMTP session in the next report. Consequences: 1. If we use the same Postfix MTA to send TLSRPT notifications, then there needs a way to signal that TLS must be optional, and that the SMTP session should not be logged to the TLSRPT library.

Good catch!

> The DKIM TXT record SHOULD contain the appropriate service type declaration, "s=tlsrpt". If not present, the receiving system MAY ignore reports lacking that service type.

Hmmm, better play with the good ones. I can see overly pedantic postmasters rejecting valuable reports because of this.

Clarification: The "s=service-type" field in the DKIM TXT record value is defined in https://datatracker.ietf.org/doc/html/rfc4871#section-3.6.1. It defaults to "*" (matches all service types), and otherwise contains a list of ":" separated service names. Currently, the only defined service type is "email". This field is not to be confused with the "s=selector-value" field in the DKIM signature header (the selector value is part of the DKIM TXT record name $selector._domainkey.$domain). Consequences: 2. If we use the same Postfix MTA to send TLSRPT notifications, then the DKIM TXT record may need to contain a field "s=tlsrpt:email". (TODO: would an explicit "s=*" be more backwards compatible or would it break something? We want to avoid triggering edge cases in software that processes TLSRPT notifications).

We could, as an advise for a best practice, also tell people to create a ***@***.*** DKIM-record as opposed to one that matches the domainpart only and set the service-type to tlsrpt for that record. Something like this: 2024-tlsrpt._domainkey.example.com "v=DKIM1; h=sha256; k=rsa; s=tlsrpt; ..." And this selector will only be assigned to a sender e.g. like this: ***@***.*** That would allow a domain to use s=email for all other addresses and only if ***@***.*** matches the selector 2024-tlsrpt and its signing settings will be used.

This would affect DNS configuration, but would not affect any code or other configuration.

ACK. My idea would also affect DKIM siging configuration. ***@***.***

…

-- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Schleißheimer Straße 26/MG,80333 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein

[BLohner]

My proposal rearding https://datatracker.ietf.org/doc/html/rfc8460#section-3: "When sending failure reports via SMTP, Sending MTAs MUST deliver reports despite any TLS-related failures and SHOULD NOT include this SMTP session in the next report."
would be to have a separate entry in master.cf to setup tolerance against TLS-related failures.

That way one could also configure that special channel to NOT report errors.
Postfix will need a configuration option to set the TLSRPT-Receiver socket name.
The special channel would not only ignore TLS-related errors and deliver the ail unencrypted if necessary, but should also be configured to use no TLSRPT-Receiver socket by specifyng something like "-o tlsrpt-socket=none" along the other options.

Of course the TLSRPT-Reporter needs to be configured to use that special service to deliver the TLSRPT reports.

[wietse-postfix]

If that 'special service' is a Postfix SMTP client, how would we route the message to that client?

If we use the same Postfix instance for sending TLSRPT notifications, then the routing must be based on a signal in a Postfix queue file. What would the signal look like? If the signal is controlled by the sender, such as a message header, body line, or envelope address, how would we prevent misuse?

[BLohner]

Something controlled by the sender within the mail (header, body line, envelope address,...) does not seem the right way because of the misuse you mention.

Can such a signal be set from within Postfix?
I think of passing some options along to the smtp client that could be set in master.cf for our special mail delivery.
My test of setting "smtp_tcp_port" within master.cf for an smtpd on a special port was not successful, it just gave me "unused parameter: smtp_tcp_port=26", but if a similar parameter could be passed along through the Postfix queue file, I think that would work, woiuldn´t it?

That way it would not be under control of an arbitrary sender form the outside but only be under control of the local sender who chooses between the normal mail delivery and the special mail delivery for TLSRPT reports.

But I have no clue if something similar exists already or how hard it would be to implement on the postfix side.

[patrickbenkoetter]

* BLohner ***@***.***>:

Something controlled by the sender within the mail (header, body line, envelope address,...) does not seem the right way because of the misuse you mention. Can such a signal be set from within Postfix? I think of passing some options along to the smtp client that could be set in master.cf for our special mail delivery.

Why not create a dedicated tlsrpt service using the Postfix smtp client within master.cf and use sender depedent routing to route a message from e.g. ***@***.*** to that service. That service yould have a special smtp_mumble_feature that takes care of the log feature we need. ***@***.***

…

-- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Schleißheimer Straße 26/MG,80333 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein

[wietse-postfix]

There are many options in the form of sender-specified information.

sender-dependent routing, a special message header, or other "reserved" information requires that such information cannot be specified by a malicious client.

That said, sender-dependent routing is a relatively robust option. In the special Postfix SMTP client we'd set "smtp_tls_security_level = may", and we'd disable smtp_tls_policy_maps and tlsrpt support.

The "reserved" sender address could also signal what domain to sign with DKIM for. We need a way to prevent spoofing of that header.

[patrickbenkoetter]

There are many options in the form of sender-specified information.

sender-dependent routing, a special message header, or other "reserved" information requires that such information cannot be specified by a malicious client.

It's quite complicated to keep someone from spoofing a message header.

That said, sender-dependent routing is a relatively robust option. In the special Postfix SMTP client we'd set "smtp_tls_security_level = may", and we'd disable smtp_tls_policy_maps and tlsrpt support.

ACK

The "reserved" sender address could also signal what domain to sign with DKIM for. We need a way to prevent spoofing of that header.

If the TLSRPT report message enters the Postfix System via SUBMISSION we could enforce the identity using smtpd_sasl_login_maps and all the relevant filters that are associated with login / envelope sender checks. Also we could use a TLS client certificate and permit only that identity to use the report sending envelope sender address.

I like both approaches, because they give us good control and because I consider them to be fairly secure, but something more simple would probably be better to foster adoption of what we do.

How about a new capability, like XCLIENT or XFORWARD to let a client signal it wants to submit a report? The smtp client could send a token and the token would be the anchor to a) verify the token owner is authorized to use the report envelope sender address and b) trigger the correct routing with all the special options we discussed above?

Not that I am keen to come up with a new capability. The benefit over a message header is that verifying the token takes place before the message is accepted and queued. Once the MTA has accepted the message things become complicated (deleting, logging...) from an operational point of view.

Of course we could also do all this before queue in a MILTER. A policy service? Both require to run an additional service and they kind of fix the problem out of the MTA. I'd prefer a solution that fixes it all within the MTA (batteries included...)

All we need - sender dependent routing, a dedicated service, smtp client transport options - is there. What we miss is a simple way to tie an envelope sender address to a specific identity and not let other identities use this particular envelope sender address. We have SMTP AUTH and TLS client certificates at hand to map an identity to an envelope sender address and existing Postfix filters like reject_sender_login_mismatch to reject identity abuse. Stick with that? Come up with something simpler?

[wietse-postfix]

RFC 8689 defines a message header "TLS-Required: no" that disables TLS policy enforcement on request:

If the ... TLS-Required message header field is used when sending a message, it asserts a request on the part of the message sender to override the default negotiation of TLS, ... by requesting that recipient-side policy mechanisms such as MTA-STS and DNS-Based Authentication of Named Entities (DANE) be ignored when relaying a message for which security is unimportant.

The RFC does not mention TLSRPT but it seems a good fit for TLSRPT summary reports. I'm in the process of adding support for this header.

(In the quote above, the ... are about an ESMTP option to require DANE or STS while sending mail; I'm not implementing that option at this time.)

[BLohner]

That´s great news!
I will add that "TLS-Required: No" header to the report emails.

[BLohner]

The RFC 8689 header got added with commit 48bc80e.

[wietse-postfix]

I'll finish the code that adds the header. This required some code refactoring that will make adding other headers easier.