Reporting "loops"

[aykevl]

I think mail servers that send reports (TLSRPT) can get stuck in a loop when not implemented properly.

Consider this:

• A user on server A sends a mail, with destination server B.
• Server B has a TLSRPT policy, and server A honors it. So after a few hours, it sends a report to server B about whether TLS was used etc.
• This report submission is a mail message sent to server B, so after ~24h server A sends another report to server B.
• Loop repeats until the TLSRPT record is removed - it doesn't need any new mail to be send from A to B.

This is mostly an implementation issue, so I don't know whether it needs to be mentioned in the specification. But I just realized this is a possibility and don't know whether this has been considered before.

I'm not sure how this works for DMARC. It has potentially the same issue, but AFAICT only when both servers implement report sending (A sends a report to B, B sends a report to A, A sends a report to B, etc.).

[abrotman]

In the draft, we do mention that TLSRPT reports should be sent ignoring TLS-related requirements (Section 3) and presumably not reported. Alternately, the reports would potentially stop being sent when the original failure scenario is resolved, and regular mail and reports can be delivered using TLS.

Though I do see your point, and I'd agree that is likely an implementation issue. Thoughts? Should we add anything?

[aykevl]

The way I understand the spec, reports are always sent regardless of whether there is a TLS failure. So this will not stop a loop.

I think it depends on whether such reporting mails are generally sent using the same mail server as all other mail (except for the TLS requirement, e.g. using REQUIRETLS) or a separate mail server. I don't know which is more likely and I don't know about the current situation with DMARC so I find it hard to say whether it is necessary.

Possible text (in bold):

• In the case of mailto, reports should be submitted to the specified email address ([@!RFC6068]). 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. This may mean that the reports are delivered in the clear. Additionally, reports sent via SMTP MUST contain a valid DKIM [@!RFC6376] signature by the reporting domain. Reports lacking such a signature MUST be ignored by the recipient. DKIM signatures must not use the "l=" attribute to limit the body length used in the signature.

[danmarg]

It's worth noting that when reports are delivered via HTTP this issue does not exist. But I think the recommended text works well.

[abrotman]

Added to the draft