Sending DMARC reports is somewhat hazardous

ZeroConcerns 3 hours ago | parent | next [-]

DMARC is a relatively recent addition to the email security space, and while it seems a bit superfluous at first, is actually quite useful! Sending and receiving the reports (which, should be noted, is entirely optional) might indeed be helped by a setup separate from the main mail handling workflow, as the 'best effort' nature and the fact that lots of systems sending DMARC reports have no business delivering mail for the sender domain in the first place are quite distinct.

Both Microsoft and Google seem to do it just fine using their main infrastructure though, so there's that. And apart from (performing or hopefully kickstarting) troubleshooting of SPF and (especially) DKIM failures, going through the forensic reports (which not everyone sends, even if they do summaries, due to message privacy concerns) will definitely satisfy your 'WTF-quota' for the day, since you get to see some spoofed messages that are usually just blackholed, and some of those are truly bizarre...

▲

bbarnett 14 minutes ago | parent | next [-]

Both Microsoft and Google seem to do it just fine

I routinely get between 5 and 10 duplicates of DMARC reports from Google for gmail. Searching on this, it's a known phenomenon. No one else has this issue. I don't get dupes from outlook.com, hotmail, yahoo, etc, etc.

But it's Google. Fairly typical for their modern quality control and engineering practices. I view them as a little like when Volkswagen stopped being run by engineers, and instead by accountants.

▲

flowerthoughts 3 hours ago | parent | prev [-]

I also don't see why the DMARC reporting would retry sending. If the receiver isn't receiving right away, surely it's okay to just drop that report to keep the queue small.

▲

ZeroConcerns 3 hours ago | parent [-]

We already had 'low effort' mail queues (for things like password reset emails: these are retried 1/2/4/8 minutes apart and don't generate bounces, other than an API flag and a metrics record), to which we added 'least effort' for DMARC reports. Retry once, then forget about the entire thing other than incrementing a counter for the destination domain.

▲

jcynix an hour ago | parent [-]

> retried 1/2/4/8 Minuten apart

That's generally not very clever, as it will impose an unneeded burden on a receiving server which actually has temporary resource problems, and it will collide with greylisting, for example.

RFC 5321 states in section "4.5.4.1. Sending Strategy" that the retry interval should be at least 30 minutes, while the give-up time needs to be at least 4–5 days:

https://datatracker.ietf.org/doc/html/rfc5321#section-4.5.4

	▲	bbarnett 7 minutes ago \| parent [-]
		SHOULD is not MUST. These capitalized terms are have very specific meanings in RFCs, see RFC https://datatracker.ietf.org/doc/html/rfc2119. SHOULD is: 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. MUST is a requirement. You left out the "however" part: In general, the retry interval SHOULD be at least 30 minutes; however, more sophisticated and variable strategies will be beneficial when the SMTP client can determine the reason for non-delivery. There's absolutely nothing wrong with a fine tuned backoff. I am not saying the specific backoff discussed by GP is best, merely that 30 minutes is absolutely not a requirement, and in fact, discussed in tandem with the fact that "more sophisticated strategies" are actually beneficial. The RFC does not agree with you. Partially quoted as you have, does not help.

▲

elric 3 hours ago | parent | prev | next [-]

Receiving DMARC reports is just as hazardous. I frequently receive spam, phishing, malware, etc on my DMARC reporting addresses. I'm somewhat surprised I haven't seen any zip-bombs in DMARC reports yet.

Rejecting DMARC reports from any sender that doesn't have a correct SPF/DKIM/DMARC setup is the bare minimum.

▲

mmsc 3 hours ago | parent | prev [-]

>I assume that putting a 'rua=' into your DMARC record makes it look more legitimate to (some) receiving systems.

Yes, Gmail for example will drop emails from mass-senders that don't implement both SPF and DKIM.

	▲	ZeroConcerns 3 hours ago \| parent [-]
		Still the 'r' parameters (reporting) in the DMARC record are optional, and there is no indication their presence bestows additional legitimacy to a sender. (For me, it's sort-of the opposite: there are fun spam patterns to be found in DMARC records with reporting addresses!)