dragoangel
commented
5 months ago Not the case. If you think it's good to have tls report parser - it should be dedicated project. Mailcow should not include such analytics tool, it greatly impact stack and not much needed because mailcow not have problems with tls ;) - all your reports will be always "green"
If people would need it - they can setup dedicated project, but not have it a part of big salt pan. Sapt pans projects that tries to cover anything no matter what price end up badly. They looks and works as Frankenstein, hardly understandable and badly maintained.
There is parsedmarc Project available that parse email reports for dmarc and there is a FR to support tls reports parsing, look there please. Deveoper now working on Implementation and requested to help with testing.
Also people can decide to use SaaS to analyze such reports.
thumpco
Summary
Request to add TLS Reporting functionality per RFC: https://www.rfc-editor.org/rfc/rfc8460.html
This would allow mailcow to provide TLS Reports (similar to DMARC Reports) per the above RFC.
From what I can tell this would require:
1) Mailcow to support separate/multiple dkim selectors for the domain sending/signing the outbound TLS Reports. Per RFC, it appears the outbound TLS reports should be signed by a dkim key with the service type declaration, "s=tlsrpt" (vs "s=email" as used by mailcow). It's unclear to me if "s=*" would suffice or if multiple service types can be listed for a single dkim key (as an alternative to multiple dkim selectors/keys). https://www.rfc-editor.org/rfc/rfc8460.html#page-6
2) Mailcow to support URI POST reporting mechanism (required alternative to SMTP reporting per RFC)
3) Mailcow to ignore TLS errors for the reporting session and exempt the reporting email from the report itself.
4) Mailcow to generate TLS report content.
Motivation
Provide compliance with latest RFC standards being implemented for DANE compliant email servers.
Additional context
No response