Can we go slightly off topic to review why the report does not include the destination domain?
That data element seems a lot more relevant than a tertiary signature. I can see that domain identification and disaggregation could significantly increase the size of reports from Gsuite and Office365, assuming that they currently aggregate all domains. This could be problematic for both them and for the recipient. On Mon, Jan 25, 2021, 1:38 PM Alessandro Vesely <[email protected]> wrote: > On Mon 25/Jan/2021 18:59:16 +0100 Brotman, Alex wrote: > > > > I’m not suggesting that we add anything that would report “Signature > > validation not attempted”, that sounds horrible. Will the original > source > > potentially care that the message was signed in three other places as the > > message bounced around? > > It can be useful to understand the mail flow. For example, a signature by > a > Mediator can reveal a mailing list, even if the receiver didn't evaluate > it. > > > > Should we put the onus on the reporting entity to do the filter out the > > non-aligned (what if none aligned) signatures, or just realize it’s some > > automated job and including all logged/validated signatures is the better > > way? > > The order in which signatures appear in a report can be significant too. > > > Best > Ale > -- > > > > > > > > >
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
