mailto notifications may need custom service type in DKIM TXT record

[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

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.

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 type names. Currently, the only defined service type is "email".

• The "s=service-type" 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:

• If we use the same Postfix MTA to send TLSRPT notifications, then the DKIM TXT record needs to match a service type of "tlsrpt". The implicit default ("s=*") should work. However, domains whose DKIM TXT record specifies an explicit service type (like "s=email") would need to configure "s=tlsrpt:email".

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

[patrickbenkoetter]

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

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.

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 type names. Currently, the only defined service type is "email".

* The "s=service-type" 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:

* If we use the same Postfix MTA to send TLSRPT notifications, then the DKIM TXT record needs to match a service type of "tlsrpt". The implicit default ("s=*") should  work. However, domains whose DKIM TXT record specifies an explicit service type (like "s=email") would need to configure "s=tlsrpt:email".

We could, as an advise for a best practice, also tell people to create a more specific localpart@domainpart DKIM signing policy that will override the less specific, default @domainpart-policy anytime a message from localpart@domainpart sends a message.

Note

DKIM signing programs select policies by specificity. localpart@domainpart has a higher specificity than domainpart only and any policy associated with localpart@domainpart would be preferred over a policy for domainpart only.

So if a message from localpart@domainpart passed the DKIM signing service it would use a dedicated signing policy and refer to that using a dedicated selector, e.g. like 2024-tlsrpt as I use in the following example. A receiver would lookup that selector in DNS and receive the signing key along with the required s=tlsrpt service type:

2024-tlsrpt._domainkey.example.com.    "v=DKIM1; h=sha256; k=rsa; s=tlsrpt; ..."

This would allow a domain to use s=email for all other addresses and only if tlsrpt@reports.example.com 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.

p@rick