Open wietse-postfix opened 1 month ago
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 thandomainpart
only and any policy associated withlocalpart@domainpart
would be preferred over a policy fordomainpart
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
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
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:
This would affect DNS configuration, but would not affect any code or other configuration.