On Fri 04/May/2018 21:37:35 +0200 Scott Kitterman via dmarc-discuss wrote: > > Shouldn't it be possible to de-duplicate these based on message ID *before* > sending aggregate reports back? Can/should this be added to DMARC the next > time the specification is updated? [my emphasis]
The "before" I emphasized above suggests that the message-id won't make it into the final report, doing so would seriously inflate the report itself. However, in order to envisage the effect, let's suppose message-id is part of a draft report at the sender, for example right after the count field in a tabular view[*]: Source IP Count Message-id Disposition SPF ... 192.0.2.1 12 blob1@domain none ✗ Fail ... 192.0.2.2 1 blob1@domain none ✓ Pass ... 192.0.2.3 1 blob2@domain none ✓ Pass ... ... Assuming message-id's are reliable, that table shows two messages, one of which was received 13 times. The second message was received just once, but that doesn't mean it had a single recipient, does it? So, if the multi-destination delivery of a single message results from an expansion (a.k.a. explosion) performed by external relays, the count is going to be higher than for expansions performed internally. Your proposal is to substitute "12" with "1" in the draft report, and then cut the message-id, group by source IP, From: domain (not showed), and results while counting just the rows, correct? That technique wouldn't fully eliminate the inconsistency, because equivalent copies of a message may come from different sources. Thinking of the tricks MTAs deploy to break long recipient lists into multiple messages with shorter list sizes, possibly relayed by different mailouts, tells me that the count field cannot be precise in any case. It is a rough estimate of the results' impact. In that sense, "12" tells you that the SPF failures exemplified above are more important than the two passes, in case you were thinking about hardening your policy. I'd keep it as is. jm2c Ale -- [*] https://en.wikipedia.org/wiki/DMARC#Aggregate_reports _______________________________________________ dmarc-discuss mailing list [email protected] http://www.dmarc.org/mailman/listinfo/dmarc-discuss NOTE: Participating in this list means you agree to the DMARC Note Well terms (http://www.dmarc.org/note_well.html)
