Re: [dmarc-ietf] Ticket #55 - Clarify legal and privacy implications of failure reports

2020-12-18 Thread Seth Blank
I think the general point is that when DMARC was originally written, there was a general expectation that forensic reports were essential to get domains to authenticate properly, and would be generally provided. We now know that forensic reports come from only a handful of places, mostly due to

Re: [dmarc-ietf] p=quarantine

2020-12-18 Thread Michael Thomas
On 12/15/20 8:01 AM, Todd Herr wrote: I'm not sure there's anything actionable about DMARC's policy values. you mean p=quarantine, or p=* in general? Obviously indirect mail flows, such as mailing lists and forwarding, complicate matters greatly here, as the handling by the intermediary

Re: [dmarc-ietf] Ticket #55 - Clarify legal and privacy implications of failure reports

2020-12-18 Thread John R Levine
Info which is encoded in such a way that only the sender can understand rises no PII concern, IMHO. A sender could cache sent messages and devise how to encode the corresponding filenames in DKIM selectors. Reporting just the failed signature would leak the whole message by reference. So

Re: [dmarc-ietf] Ticket #55 - Clarify legal and privacy implications of failure reports

2020-12-18 Thread Alessandro Vesely
On Fri 18/Dec/2020 03:39:00 +0100 John Levine wrote: In article you write: We would like to close this ticket two weeks from now, by the end of the year, so please get on it. The ticket text is just: Make it clear in privacy considerations that failure reports can provide PII well

Re: [dmarc-ietf] Ticket #28 - Failure report mail loops

2020-12-18 Thread Alessandro Vesely
On Wed 09/Dec/2020 18:22:04 +0100 Dave Crocker wrote: On 12/9/2020 7:23 AM, John R Levine wrote: No.  This is not a problem.  There is nothing to fix.  Please close this ticket. +1 Fair enough. Ticket closed. Best Ale -- ___