Re: [dmarc-ietf] Ticket #55 - Clarify legal and privacy implications of failure reports
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 PII considerations due to how reports are redacted in practice. A privacy consideration should say such a thing, specifically clarify what may be in a report that could be categorized as PII even after intended redaction, but refrain from legal advice. Seth, with schrodinger's hat On Fri, Dec 18, 2020 at 12:05 PM John R Levine wrote: > > 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 what? > > Now he knows which forwarded recipients are talking with his users. > > >> Also, whether we use the current Org domain heuristic or a tree walk > >> to find a higher level DMARC record, there is no way to reliably tell > >> the relationship between a domain publishing the rua or ruf tag and a > >> subdomain being reported. Partly this is the Holy Roman Empire > >> problem, partly the PSL is just incomplete and always will be. > > > > Right. A user can use a submission server which is trusted not to relay > > messages to third parties. Yet, ruf= can point to a completely > different > > environment. > > No, that's not what I was talking about. I am the registry for > someplace.ny.us, and the county government is co.someplace.ny.us. I get > all of the DMARC reports for the county's mail. Oops. I'm not being > hypothetical here. > > > To avoid that risk, one can send just the header, and redact it > > appropriately. Should the spec give practical advice about how to do > that? > > Since it doesn't solve the problem, no. > > >>> Any lawyers in this WG? > >> > >> The IETF most definitely does not provide legal advice. > > > > That sounds more like a bug than a feature. We should at least check > that > > any advice given is legally sound. > > There are 195 countries in the world, and many like the US have states or > provinces with different legal systems. Legally sound where? > > R's, > John > > ___ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > -- *Seth Blank* | VP, Standards and New Technologies *e:* s...@valimail.com *p:* 415.273.8818 This email and all data transmitted with it contains confidential and/or proprietary information intended solely for the use of individual(s) authorized to receive it. If you are not an intended and authorized recipient you are hereby notified of any use, disclosure, copying or distribution of the information included in this transmission is prohibited and may be unlawful. Please immediately notify the sender by replying to this email and then delete it from your system. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] p=quarantine
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 host(s) can and will lead to a higher percentage of authentication failures. The community has attempted to mitigate this problem; RFC5322.From header rewriting, RFC5321.From header rewriting (e.g., SRS), and ARC are among the attempts put forth so far, but none have been deemed The Solution(tm) yet. In my opinion, ARC has promise, because if a message reaches me as a receiver or even intermediary and fails the authentication checks I perform, ARC header sets in the message can tell me whether or not such checks passed at previous hops *if I trust the entities that inserted those ARC header sets*. In an earlier thread, I floated an idea about ARC sealer reputation, but it didn't draw much response, so I'll float it here again in the hopes that it does. We've always been able to check the reputation of lists that resign the message. The reputation is the previously (un)solved problem. Mike ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Ticket #55 - Clarify legal and privacy implications of failure reports
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 what? Now he knows which forwarded recipients are talking with his users. Also, whether we use the current Org domain heuristic or a tree walk to find a higher level DMARC record, there is no way to reliably tell the relationship between a domain publishing the rua or ruf tag and a subdomain being reported. Partly this is the Holy Roman Empire problem, partly the PSL is just incomplete and always will be. Right. A user can use a submission server which is trusted not to relay messages to third parties. Yet, ruf= can point to a completely different environment. No, that's not what I was talking about. I am the registry for someplace.ny.us, and the county government is co.someplace.ny.us. I get all of the DMARC reports for the county's mail. Oops. I'm not being hypothetical here. To avoid that risk, one can send just the header, and redact it appropriately. Should the spec give practical advice about how to do that? Since it doesn't solve the problem, no. Any lawyers in this WG? The IETF most definitely does not provide legal advice. That sounds more like a bug than a feature. We should at least check that any advice given is legally sound. There are 195 countries in the world, and many like the US have states or provinces with different legal systems. Legally sound where? R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Ticket #55 - Clarify legal and privacy implications of failure reports
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 beyond a domain name, and are not sent by most receivers. The current text says that, but it should also point out that redaction does not always remove PII. Info about sender or recipient might be encoded in non-obvious places such as the Message-ID or DKIM selectors.* 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 what? Also, whether we use the current Org domain heuristic or a tree walk to find a higher level DMARC record, there is no way to reliably tell the relationship between a domain publishing the rua or ruf tag and a subdomain being reported. Partly this is the Holy Roman Empire problem, partly the PSL is just incomplete and always will be. Right. A user can use a submission server which is trusted not to relay messages to third parties. Yet, ruf= can point to a completely different environment. By reporting failures (which could be each and every message) a report producer can be of service to covert communication tracking. To avoid that risk, one can send just the header, and redact it appropriately. Should the spec give practical advice about how to do that? Any lawyers in this WG? The IETF most definitely does not provide legal advice. That sounds more like a bug than a feature. We should at least check that any advice given is legally sound. Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Ticket #28 - Failure report mail loops
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 -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
