Re: [dmarc-ietf] Aggregate Reporting - "Not Evaluated" result

[Alessandro Vesely <[e-mail]>]

On Mon 24/Oct/2022 18:36:07 +0200 Dotzero wrote:
> On Mon, Oct 24, 2022 at 5:47 AM Alessandro Vesely <[e-mail]> wrote:
>> On Sun 23/Oct/2022 14:16:30 +0200 Dotzero wrote:
>>> On Sun, Oct 23, 2022 at 6:29 AM Alessandro Vesely <[e-mail]> wrote:
>>>> On Sat 22/Oct/2022 18:25:55 +0200 Dotzero wrote:
>>>> 
>>>> [...]
>>>> ARC too is a kind of unaligned signature, albeit with a bunch of
>>>> additions. The extra information it carries, designed to bestow enough
>>>> trust in the chain of custody to outweigh the self-referential reliance of
>>>> aligned From:, doesn't substantially change the semantic of DKIM
>>>> signatures.  And we should say how to report it, sooner or later.
>>> ARC != DMARC. It is a separate RFC that gives participants an alternative
>>> means of evaluating mail flows when DKIM signatures are broken. Nothing
>>> more and nothing less.
> 
> ARC is a different signature not an "unaligned signature".


Right.  Usually, it is not aligned with From:, which brings about a different 
question:  Useful ARC reporting should also target the ARC sealers, not just 
the From: domain owner.


>> Conflicting protocols?  ARC was devised by the DMARC WG, during the phase
>> of "improving the identification of legitimate sources that do not
>> currently conform to DMARC requirements."  So, yes, on the one hand, since
>> unaligned signatures don't conform to DMARC requirements, they're not
>> DMARC.  On the other hand, as a fusion of deterministic authentication
>> techniques and domain policies, DMARC is intrinsically extensible.  For
>> aggregate reporting in particular, we explicitly provide for extensions. >
> Splitting out reporting is a good thing. Perhaps it should be renamed so
> that it is not DMARC centric. I would suggest the fact that something (ARC)
> which is not DMARC is included in the reporting that was developed as an
> integral part of DMARC is a matter of convenience more than anything else.


We already split reporting from the main spec.  Changing name is difficult 
because the places to publish consumer addresses are the DMARC records.  Those 
are also an extensible thing in their own respect, as one can always add new 
tags to address new functionality.

It seems it would be easier to coin a new term to indicate the DMARC protocol 
proper, that is policy and alignment.  Is it really necessary to make that 
distinction?


>>>> I'm not proposing to mandate the evaluation of any evaluable item. 
>>>> However, I'd neither discourage it.  Perhaps technology will provide us 
>>>> with ecological sources of energy.
>>>
>>> There is nothing wrong with using whatever data points you have available. 
>>> That doesn't necessarily mean that such evaluations and choices are DMARC.
>>
>> If ARC were a separate thing, it'd make no sense to include its data in 
>> DMARC aggregate reports.
> 
> As I wrote above, it is more a matter of convenience than anything else. 
> Generating separate ARC reports is duplicative effort from both a report 
> generating perspective as well as consumption of those reports.


Agreed.  If it weren't for the different categories (std versus exp) we could 
specify the ARC scheme directly.


>> I think what we could do is to identify some criteria that a report 
>> generator may follow, such as doing everything, reporting up to X
>> signatures, or doing SPF only.  Such meta data could be useful to report
>> consumers, along with the generator's software/version.

Best
Ale
--