Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-aggregate-reporting-08.txt

[Scott Kitterman <[e-mail]>]

On Tuesday, March 28, 2023 1:09:34 PM EDT Alessandro Vesely wrote:
> On Tue 28/Mar/2023 17:49:57 +0200 Scott Kitterman wrote:
> > I can live with it [the <discovery_method>] since it's optional (I
> > don't think it'll get a lot of traction), but I do think it's misplaced. 
> > I
> > think it's metadata, not message data as it's about how the receiver
> > processed the message, not about anything that was found in the message.
> 
> Agreed, it should be in <report_metadata>, before <report_id>.
> 
> In addition, couldn't we add there also a <reporting_software> or similar
> element to write the name+version of the software that collected and
> formatted the data?  The <discovery_method> probably depends on that, but
> possibly also on local system configuration.

Let's not dig the hole deeper.

Currently the purpose of aggregate reports is for receivers to provide data to 
senders so that senders can verify their email authentication is working as 
intended.  Reporting software is not at all relevant to that purpose.

That would only be relevant for email receivers to provide data to senders so 
that senders can provide feedback to the receivers and provide data to the 
receiver (which they already have) that demonstrates they are using buggy 
software.

Please.  No.  Everything we add has a cost that translates into reduced 
adoption.  We really should not be adding nice to have items, which this 
definitely is.

Scott K