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

On 1/7/2021 2:14 AM, Alessandro Vesely wrote: On Wed 06/Jan/2021 00:55:41 +0100 Dave Crocker wrote: On 1/5/2021 3:50 PM, Michael Thomas wrote: Quit cutting out needed context to make your points. The study directly contradicts your categorical statement. Except that it doesn't. Feel free

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

On Wed 06/Jan/2021 00:55:41 +0100 Dave Crocker wrote: On 1/5/2021 3:50 PM, Michael Thomas wrote: Quit cutting out needed context to make your points. The study directly contradicts your categorical statement. Except that it doesn't. Feel free to provide an serious explanation of why you

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

On 1/6/2021 10:06 AM, Michael Thomas wrote: The AD said to stop an hour ago. So stop. And yet, you didn't. I only just, finally, read his directive.  what's your excuse? d/ -- Dave Crocker dcroc...@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter American Red Cross

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

The AD said to stop an hour ago. So stop. On 1/6/21 10:04 AM, Dave Crocker wrote: On 1/6/2021 7:07 AM, Michael Thomas wrote: You are literally telling me what I knew at the time. They are literally doing nothing of the kind.  Since you think otherwise, please provide sufficient analysis

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

On 1/6/2021 7:07 AM, Michael Thomas wrote: You are literally telling me what I knew at the time. They are literally doing nothing of the kind.  Since you think otherwise, please provide sufficient analysis of what they actually wrote to explain your rather divergent interpretation of it.

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

On 1/6/2021 6:41 AM, Michael Thomas wrote: Um, dude, I was one of the authors of IIM. You're literally claiming to know more than me about what was in my head. Um, dude, she was claiming there was operational experience, upon which DKIM was based.  I don't recall IIM having operational

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

On Wed, Jan 6, 2021 at 7:26 AM Michael Thomas wrote: > No, you are literally telling everyone else how things were. In fact, > there was a lot of data. You are the one who claimed that everything was in > your head and the rest of us have no clue. - "DKIM itself was a leap of > faith" and that

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

On 1/6/21 7:17 AM, Dotzero wrote:You are literally telling me what I knew at the time. It was a lot of the reason that we got push back to form the DKIM working group. It wasn't until I read that paper that I got some concrete feel for how it affected things, and that was 16 years later. The

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

On Wed, Jan 6, 2021 at 10:07 AM Michael Thomas wrote: > > On 1/6/21 6:59 AM, Dotzero wrote: > > > > On Wed, Jan 6, 2021 at 9:41 AM Michael Thomas wrote: > >> >> On 1/5/21 10:02 PM, Dotzero wrote: >> >> >> >> On Tue, Jan 5, 2021 at 8:19 PM Michael Thomas wrote: >> >> >>> No it was an unalloyed

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

On 1/6/21 6:59 AM, Dotzero wrote: On Wed, Jan 6, 2021 at 9:41 AM Michael Thomas > wrote: On 1/5/21 10:02 PM, Dotzero wrote: On Tue, Jan 5, 2021 at 8:19 PM Michael Thomas mailto:m...@mtcc.com>> wrote: No it was an unalloyed good that you brought

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

On Wed, Jan 6, 2021 at 9:41 AM Michael Thomas wrote: > > On 1/5/21 10:02 PM, Dotzero wrote: > > > > On Tue, Jan 5, 2021 at 8:19 PM Michael Thomas wrote: > > >> No it was an unalloyed good that you brought that up. We can use a much >> more data-driven approach rather than opinion and

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

On 1/5/21 10:02 PM, Dotzero wrote: On Tue, Jan 5, 2021 at 8:19 PM Michael Thomas > wrote: No it was an unalloyed good that you brought that up. We can use a much more data-driven approach rather than opinion and conjecture. It would be good for it

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

On Tue, Jan 5, 2021 at 8:19 PM Michael Thomas wrote: > No it was an unalloyed good that you brought that up. We can use a much > more data-driven approach rather than opinion and conjecture. It would > be good for it to be required reading for everybody on this working > group, and not snarled

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

On 1/5/21 5:22 PM, Dave Crocker wrote: On 1/5/2021 5:19 PM, Michael Thomas wrote: and not snarled at as a heresy. Michael, That was yet another ad hominem from you.  As well as being grossly inaccurate. Your issue is with the authors of the study. Leave me out of this. Mike

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

On 1/5/2021 5:19 PM, Michael Thomas wrote: and not snarled at as a heresy. Michael, That was yet another ad hominem from you.  As well as being grossly inaccurate. d/ -- Dave Crocker dcroc...@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter American Red Cross

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

On 1/5/21 5:11 PM, Douglas Foster wrote: Sorry that my name was dragged into this.   The study in question was one  provided by Laura Atkins several months ago.   I forwarded it to Michael to bring him up to speed.   To date, it is the only study submitted to this group. I was not trying to

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

Sorry that my name was dragged into this. The study in question was one provided by Laura Atkins several months ago. I forwarded it to Michael to bring him up to speed. To date, it is the only study submitted to this group. I was not trying to introduce new information or re-ignite this

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

On 1/5/2021 3:50 PM, Michael Thomas wrote: Quit cutting out needed context to make your points. The study directly contradicts your categorical statement. Except that it doesn't.  Feel free to provide an serious explanation of why you think otherwise, but please put some effort into

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

On 1/5/21 3:44 PM, Dave Crocker wrote: On 1/5/2021 2:57 PM, Michael Thomas wrote: Oh?  A trust indicator to a user, flagging a domain name, isn't pretty much the same?  Please explain. Pretty much != same. A trust indicator, to a user, flagging a domain name. Essentially the same

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

On 1/5/2021 2:57 PM, Michael Thomas wrote: Oh?  A trust indicator to a user, flagging a domain name, isn't pretty much the same?  Please explain. Pretty much != same. A trust indicator, to a user, flagging a domain name. Essentially the same user-oriented mechanism. Web vs. email.  Why

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

On 1/5/21 2:43 PM, Dave Crocker wrote: Your focus on email, as somehow distinctive, would need some basis for ignoring the web experience.  Feel free to provide it. Your example of web is fraught because web stuff has had visual indicators for decades now, and trying to compare EV certs

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

Your focus on email, as somehow distinctive, would need some basis for ignoring the web experience.  Feel free to provide it. Your example of web is fraught because web stuff has had visual indicators for decades now, and trying to compare EV certs isn't especially a good example because the

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

On 1/5/21 2:07 PM, Dave Crocker wrote: On 1/5/2021 1:58 PM, Michael Thomas wrote: On 1/5/21 1:49 PM, Dave Crocker wrote: On 1/5/2021 1:20 PM, Michael Thomas wrote: On 1/5/21 1:18 PM, Dave Crocker wrote: On 1/5/2021 12:55 PM, Michael Thomas wrote: It also says with actual data that your

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

On 1/5/2021 1:58 PM, Michael Thomas wrote: On 1/5/21 1:49 PM, Dave Crocker wrote: On 1/5/2021 1:20 PM, Michael Thomas wrote: On 1/5/21 1:18 PM, Dave Crocker wrote: On 1/5/2021 12:55 PM, Michael Thomas wrote: It also says with actual data that your assertion that users can't be trusted for

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

On 1/5/21 1:49 PM, Dave Crocker wrote: On 1/5/2021 1:20 PM, Michael Thomas wrote: On 1/5/21 1:18 PM, Dave Crocker wrote: On 1/5/2021 12:55 PM, Michael Thomas wrote: It also says with actual data that your assertion that users can't be trusted for anything is not correct. I didn't say that. 

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

On 1/5/2021 1:20 PM, Michael Thomas wrote: On 1/5/21 1:18 PM, Dave Crocker wrote: On 1/5/2021 12:55 PM, Michael Thomas wrote: It also says with actual data that your assertion that users can't be trusted for anything is not correct. I didn't say that.  And it didn't say that. "Also, receiver

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

On 1/5/21 1:18 PM, Dave Crocker wrote: On 1/5/2021 12:55 PM, Michael Thomas wrote: It also says with actual data that your assertion that users can't be trusted for anything is not correct. I didn't say that.  And it didn't say that. "Also, receiver filtering engines are all that matter."

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

On 1/5/2021 12:55 PM, Michael Thomas wrote: It also says with actual data that your assertion that users can't be trusted for anything is not correct. I didn't say that.  And it didn't say that. d/ -- Dave Crocker dcroc...@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter American

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

On 1/5/21 12:48 PM, Dave Crocker wrote: On 1/5/2021 12:11 PM, Michael Thomas wrote: On 1/5/21 12:04 PM, Dave Crocker wrote: 1. I've looked back over his postings to this mailing list and am not finding the link you refer to.  Please post it (again). 2. A single study is unlikely to be

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

On 1/5/2021 12:11 PM, Michael Thomas wrote: On 1/5/21 12:04 PM, Dave Crocker wrote: 1. I've looked back over his postings to this mailing list and am not finding the link you refer to.  Please post it (again). 2. A single study is unlikely to be definitive about much of anything.

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

On 1/5/21 12:04 PM, Dave Crocker wrote: On 1/5/2021 11:34 AM, Michael Thomas wrote: On 1/5/21 11:22 AM, Dave Crocker wrote: From: header field rewriting demonstrates that DMARC is, indeed, trivial to defeat (or rather, to route around.)  Also, receiver filtering engines are all that matter. 

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

On 1/5/2021 11:34 AM, Michael Thomas wrote: On 1/5/21 11:22 AM, Dave Crocker wrote: From: header field rewriting demonstrates that DMARC is, indeed, trivial to defeat (or rather, to route around.)  Also, receiver filtering engines are all that matter.  Real-time actions by recipients are

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

On 1/5/21 11:22 AM, Dave Crocker wrote: From: header field rewriting demonstrates that DMARC is, indeed, trivial to defeat (or rather, to route around.)  Also, receiver filtering engines are all that matter.  Real-time actions by recipients are demonstrably irrelevant to DMARC (and all

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

On 1/5/2021 10:28 AM, Kurt Andersen (b) wrote: > Because recipients often can’t see (or don’t pay attention to) the domain > name and the reputation system you postulate doesn’t exist. OTOH, getting > alignment avoids a restrictive policy that might be associated with

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

On 5 Jan 2021, at 10:17, Paypal security confirm your password now wrote: reputation for the domain. I have trouble imagining why anyone would think it's a good idea to get alignment by using third party domains that recipients don't know. Because recipients often can’t see (or don’t pay

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

On Tue, Jan 5, 2021 at 10:18 AM Paypal security confirm your password now < jo...@taugh.com> wrote: > >> reputation for the domain. I have trouble imagining why anyone would > >> think it's a good idea to get alignment by using third party domains > >> that recipients don't know. > > > > Because

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

reputation for the domain. I have trouble imagining why anyone would think it's a good idea to get alignment by using third party domains that recipients don't know. Because recipients often can’t see (or don’t pay attention to) the domain name and the reputation system you postulate doesn’t

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

On 4 Jan 2021, at 9:46, John Levine wrote: Similarly, DMARC alignment tells you nothing unless you also have a reputation for the domain. I have trouble imagining why anyone would think it's a good idea to get alignment by using third party domains that recipients don't know. Because

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

I have not seen an identity problem with ESPs, bevause messages are received directly. They consistently use their own domain for MailFrom to ensure SPF pass, and the client domain for From.Domains that use DMARC enforcement have signatures. Additionally, the From domain correctly presents

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

On Mon 04/Jan/2021 13:22:20 +0100 Laura Atkins wrote: On 4 Jan 2021, at 11:50, Alessandro Vesely wrote: Lets define "legitimate mail" as used in my proposed text to mean "delivery is desired by the intended recipient and the message contains nothing that threatens the interest of the user,

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

On 1/4/21 9:46 AM, John Levine wrote: Similarly, DMARC alignment tells you nothing unless you also have a reputation for the domain. I have trouble imagining why anyone would think it's a good idea to get alignment by using third party domains that recipients don't know. You don't need to

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

Similarly, DMARC alignment tells you nothing unless you also have a reputation for the domain. Authentication creates a noise-free basis for developing an indentifier's reputation. Any activity involving an authenticated identifier is, in fact, the responsibility of the agency

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

In article <123e18e2-71ab-4946-b886-a12a735aa...@wordtothewise.com> you write: >There is absolutely nothing stopping a phisher from taking advantage of this. >In fact, phishers currently do send DMARC verified email where the >domain in the 5322.from is unrelated to the links in the message or to

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

> On 4 Jan 2021, at 11:50, Alessandro Vesely wrote: > > > >> Lets define "legitimate mail" as used in my proposed text to mean "delivery >> is desired by the intended recipient and the message contains nothing that >> threatens the interest of the user, the interest of the user's network, or

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

On Sun 03/Jan/2021 17:09:22 +0100 John R Levine wrote: On Sun, 3 Jan 2021, Alessandro Vesely wrote: I don't think so.  There is a very practical outcome.  We should expand Section 9.5, "Interoperability Issues" and say something actually workable. With some trepidation I ask, like what?

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

On Sun 03/Jan/2021 20:56:59 +0100 Douglas Foster wrote: You can disagree about whether this wording is appropriate, but there should be no disagreement about the scope problem. We do not have a protocol which can handle all situations, and much of our discussion is caused by those who apply

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

You can disagree about whether this wording is appropriate, but there should be no disagreement about the scope problem. We do not have a protocol which can handle all situations, and much of our discussion is caused by those who apply DMARC to situations where it does not work. Lets define

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

On Sun, 3 Jan 2021, Alessandro Vesely wrote: I don't think so. There is a very practical outcome. We should expand Section 9.5, "Interoperability Issues" and say something actually workable. With some trepidation I ask, like what? If it's anything like telling mailing lists how to rewrite

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

On Sat 02/Jan/2021 19:47:18 +0100 John Levine wrote: In article <8f438ed3-88cb-58dd-6a12-630e4000e...@tana.it>, Alessandro Vesely wrote: The entire problem with catering to the long tail is that it is holding hostage better email security. We should stop doing that. There is no right to

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

On Sat 02/Jan/2021 19:53:41 +0100 Douglas Foster wrote: Regarding this section: Experience with DMARC has revealed some issues of interoperability with email in general that require due consideration before deployment, particularly with configurations that can cause mail to be

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

The entire problem with catering to the long tail is that it is holding hostage better email security. We should stop doing that. The entire problem with statements like these is that they provide a cavalier dismissal of established practice, while lacking thoughtful cost/benefit detail,

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

Regarding this section: Experience with DMARC has revealed some issues of interoperability with email in general that require due consideration before deployment, particularly with configurations that can cause mail to be rejected. These are discussed in Section 9. I suggest

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

In article <8f438ed3-88cb-58dd-6a12-630e4000e...@tana.it>, Alessandro Vesely wrote: >> The entire problem with catering to the long tail is that it is holding >> hostage >> better email security. We should stop doing that. There is no right to >> stasis >> forevermore. If the scouts email

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

On Thu 31/Dec/2020 19:36:15 +0100 Michael Thomas wrote: On 12/31/20 10:22 AM, John R Levine wrote: To what?  The Yahoo address is the only address the scout troop has? Copy that to Reply-To: and write a mangled From: that looks troopy but passes DMARC.  Just like MLMs do. Lists at MLMs

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

On 12/31/20 10:22 AM, John R Levine wrote: To what?  The Yahoo address is the only address the scout troop has? Copy that to Reply-To: and write a mangled From: that looks troopy but passes DMARC.  Just like MLMs do. Lists at MLMs have names that the subscribers will recognize, but the

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

To what?  The Yahoo address is the only address the scout troop has? Copy that to Reply-To: and write a mangled From: that looks troopy but passes DMARC. Just like MLMs do. Lists at MLMs have names that the subscribers will recognize, but the scout troop only has the Yahoo address. There

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

On Thu 31/Dec/2020 18:51:10 +0100 John R Levine wrote: The main effect is that the mail they'd been sending from their ESP with their Yahoo address on the From: line used to work, and now falls on the floor or worse. Why can't the ESPs do From: rewriting? To what?  The Yahoo address is the

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

The main effect is that the mail they'd been sending from their ESP with their Yahoo address on the From: line used to work, and now falls on the floor or worse. Why can't the ESPs do From: rewriting? To what? The Yahoo address is the only address the scout troop has? Regards, John Levine,

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

On Thu 31/Dec/2020 18:27:26 +0100 John R Levine wrote: Before we do that I think we should revisit whether we have one reporting draft or two. That issue only touches ticket #55 because it's the only one which called for altering the I-D's text. Also having a -01 beside -00 is irrelevant to

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

On Thu 31/Dec/2020 17:00:29 +0100 John Levine wrote: In article <7dc4203e-1140-8808-776c-e80e5b5f6...@tana.it> you write: Many Girl Scout troops were affected when Yahoo published p=reject. Which is probably why John brought it up. This isn’t a hypothetical, this is things that we know

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

Before we do that I think we should revisit whether we have one reporting draft or two. On Thu, 31 Dec 2020, Alessandro Vesely wrote: On Thu 24/Dec/2020 10:35:10 +0100 Alessandro Vesely wrote: On Thu 24/Dec/2020 03:39:03 +0100 Tim Wicinski wrote: I Believe I agree with the current version,

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

On Thu 24/Dec/2020 10:35:10 +0100 Alessandro Vesely wrote: On Thu 24/Dec/2020 03:39:03 +0100 Tim Wicinski wrote: I Believe I agree with the current version, but can someone post what we think is the final text? I posted it here:

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

In article <7dc4203e-1140-8808-776c-e80e5b5f6...@tana.it> you write: >> Many Girl Scout troops were affected when Yahoo published p=reject. Which is >> probably why John brought it up. This isn’t a hypothetical, this is things >> that >> we know actually happened and real world effects of

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

On Thu 31/Dec/2020 11:15:07 +0100 Laura Atkins wrote: On 30 Dec 2020, at 23:22, Jim Fenton In article <14d833ce-0ae0-f818-fd4f-95769266a...@mtcc.com you write: On 12/29/20 12:10 PM, John Levine wrote: A lot of tiny non-profits like Girl Scout troops use email addresses at webmail providers

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

> On 30 Dec 2020, at 23:22, Jim Fenton wrote: > > On 29 Dec 2020, at 12:59, John Levine wrote: > >> In article <14d833ce-0ae0-f818-fd4f-95769266a...@mtcc.com> you write: >>> >>> On 12/29/20 12:10 PM, John Levine wrote: A lot of tiny non-profits like Girl Scout troops use email addresses

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

On 29 Dec 2020, at 12:59, John Levine wrote: In article <14d833ce-0ae0-f818-fd4f-95769266a...@mtcc.com> you write: On 12/29/20 12:10 PM, John Levine wrote: A lot of tiny non-profits like Girl Scout troops use email addresses at webmail providers and send their announcements through ESPs like

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

On 12/29/20 12:59 PM, John Levine wrote: In article <14d833ce-0ae0-f818-fd4f-95769266a...@mtcc.com> you write: On 12/29/20 12:10 PM, John Levine wrote: A lot of tiny non-profits like Girl Scout troops use email addresses at webmail providers and send their announcements through ESPs like

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

In article <14d833ce-0ae0-f818-fd4f-95769266a...@mtcc.com> you write: > >On 12/29/20 12:10 PM, John Levine wrote: >> A lot of tiny non-profits like Girl Scout troops use email addresses >> at webmail providers and send their announcements through ESPs like >> Constant Contact and Mailchimp. This

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

My review of messages from Constant Contact and other major E.S.P.s is that they do obtain and use a DKIM selector when the domain has dmarc enforcement. Earlier in this discussion I was assured that conditionally applying the right signature was not a significant burden for them. Scaling does

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

On 12/29/20 12:10 PM, John Levine wrote: In article <5d0793ae-de65-cd1d-32ef-c909202a0...@mtcc.com> you write: On 12/29/20 10:59 AM, John Levine wrote: Don't forget o Normal forwarding of SPF validated mail o Authorized third party senders with no access to DKIM keys If by

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

In article <5d0793ae-de65-cd1d-32ef-c909202a0...@mtcc.com> you write: > >On 12/29/20 10:59 AM, John Levine wrote: >> >> Don't forget >> >> o Normal forwarding of SPF validated mail >> o Authorized third party senders with no access to DKIM keys >> >If by "authorized" you mean authorized by the

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

On Tue 29/Dec/2020 18:22:18 +0100 ned+dmarc wrote: On Mon 28/Dec/2020 22:20:55 +0100 Todd Herr wrote: DMARC validation failures can be caused either due to legitimate mail (i.e., mail originated by or on behalf of the publisher of the DMARC policy, a.k.a., the domain owner) failing

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

On 12/29/20 10:59 AM, John Levine wrote: Don't forget o Normal forwarding of SPF validated mail o Authorized third party senders with no access to DKIM keys If by "authorized" you mean authorized by the originating domain, I don' t have a lot of sympathy since they can delegate them a

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

In article <01rtqrkld8qk004...@mauve.mrochek.com> you write: >I think a list of possible failure causes would be nice to have, because >a lot of people seem to think that DMARC is a completely reliable mechanism. > >I'm not entirely convinced this document is the place for it, but OTOH >I'm not

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

On Mon 28/Dec/2020 22:20:55 +0100 Todd Herr wrote: > > DMARC validation failures can be caused either due to legitimate mail > (i.e., mail originated by or on behalf of the publisher of the DMARC > policy, a.k.a., the domain owner) failing authentication checks due to a > shortcoming in the

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

On 12/28/20 11:03 PM, Murray S. Kucherawy wrote: On Mon, Dec 28, 2020 at 7:23 AM > wrote: P.S. I hadn't looked at RFC 6589 before, and I  have to say I find its standards-track status to be nothing short of astonishing. How on earth do you assess

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

On Mon 28/Dec/2020 15:54:24 +0100 ned+dmarc wrote: > >> I still think it'd be a good idea to mention RFC 6590... > > Why? RFC 6590 documents a generic approach to partial information hiding. It > does not specify how to apply this technique to DMARC failure reports, and > doing so effectively

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

On 12/28/20 11:03 PM, Murray S. Kucherawy wrote: On Mon, Dec 28, 2020 at 7:23 AM > wrote: P.S. I hadn't looked at RFC 6589 before, and I  have to say I find its standards-track status to be nothing short of astonishing. How on earth do you assess

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

On Mon 28/Dec/2020 22:20:55 +0100 Todd Herr wrote: DMARC validation failures can be caused either due to legitimate mail (i.e., mail originated by or on behalf of the publisher of the DMARC policy, a.k.a., the domain owner) failing authentication checks due to a shortcoming in the

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

On Mon 28/Dec/2020 15:54:24 +0100 ned+dmarc wrote: I still think it'd be a good idea to mention RFC 6590... Why? RFC 6590 documents a generic approach to partial information hiding. It does not specify how to apply this technique to DMARC failure reports, and doing so effectively requires a

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

On Mon, Dec 28, 2020 at 7:23 AM wrote: > P.S. I hadn't looked at RFC 6589 before, and I have to say I find its > standards-track status to be nothing short of astonishing. How on earth do > you > assess interoperability? > With the benefit of hindsight, that's a great question. I'd have been

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

In article you write: >I believe at one time long ago there was an idea that a second possible >usage for failure reports showing illegitimate mail was to give the domain >owner evidence to present to an abuse desk or takedown vendor to get the >illegitimate mail cut off at its source, but I

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

On Mon, Dec 28, 2020 at 3:14 PM Alessandro Vesely wrote: > On Mon 28/Dec/2020 16:48:10 +0100 Todd Herr wrote: > > > > I am not opposed to the generic warning, but the following sentence in > the > > proposed warning gives me pause: > > > > "They are meant to aid domain owners to detect why

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

On Mon 28/Dec/2020 16:48:10 +0100 Todd Herr wrote: I am not opposed to the generic warning, but the following sentence in the proposed warning gives me pause: "They are meant to aid domain owners to detect why failures reported in aggregate form occurred." The implication, to me, in

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

In article you write: >Is it not also important to note that the recipient of the failure report >(the domain owner) may not be the originator of the failed message, and >that fact should also weigh into the consideration of deciding whether to >generate such reports? The exact same issue

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

I would drop that whole third sentence, and mention sending such reports may contain PII. The document can refer the reader to non-IETF documents for information, but in general we do technical standards, and stay away from policy decisions in standards track documents. tim On Mon, Dec 28,

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

On 12/28/20 7:48 AM, Todd Herr wrote:  not a lawyer, but providing A with some information about a message that A sent to X seems different, from a privacy perspective, than providing A with some information about a message impersonating A that B sent to X, and I thought perhaps the generic

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

On Mon, Dec 28, 2020 at 9:12 AM Dotzero wrote: > > > On Mon, Dec 28, 2020 at 8:30 AM Todd Herr 40valimail@dmarc.ietf.org> wrote: > >> On Thu, Dec 24, 2020 at 1:55 PM John R Levine wrote: >> >>> >>> Security considerations >>> >>> Failure reports provide detailed information about the

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

On Thu 24/Dec/2020 19:55:07 +0100 John R Levine wrote: >> On Thu 24/Dec/2020 03:39:03 +0100 Tim Wicinski wrote: >>> I Believe I agree with the current version, but can someone post what we >>> think is the final text? > > See below, with the two changes mentioned before and Mr Copy Edit's minor >

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

On Mon, Dec 28, 2020 at 8:30 AM Todd Herr wrote: > On Thu, Dec 24, 2020 at 1:55 PM John R Levine wrote: > >> >> Security considerations >> >> Failure reports provide detailed information about the failure of a >> single message or a group of similar messages failing for the same >> reason. They

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

On Thu, Dec 24, 2020 at 1:55 PM John R Levine wrote: > > Security considerations > > Failure reports provide detailed information about the failure of a > single message or a group of similar messages failing for the same > reason. They are meant to aid domain owners to detect why failures >

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

On Thu 24/Dec/2020 19:55:07 +0100 John R Levine wrote: On Thu 24/Dec/2020 03:39:03 +0100 Tim Wicinski wrote: I Believe I agree with the current version, but can someone post what we think is the final text? See below, with the two changes mentioned before and Mr Copy Edit's minor tightening

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

On Thu 24/Dec/2020 03:39:03 +0100 Tim Wicinski wrote: I Believe I agree with the current version, but can someone post what we think is the final text? See below, with the two changes mentioned before and Mr Copy Edit's minor tightening up which I hope are not controversial. Ale said: I

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

On Thu 24/Dec/2020 03:39:03 +0100 Tim Wicinski wrote: I Believe I agree with the current version, but can someone post what we think is the final text? I posted it here: https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-failure-reporting I don't think the text is final, though. Besides

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

I Believe I agree with the current version, but can someone post what we think is the final text? tim On Wed, Dec 23, 2020 at 9:12 PM John R Levine wrote: > On Wed, 23 Dec 2020, Dotzero wrote: > > Based on my experience, I disagree that failure reports are marginal and > > seldom used. It's

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

On Wed, 23 Dec 2020, Dotzero wrote: Based on my experience, I disagree that failure reports are marginal and seldom used. It's kind of like an iceberg, mostly below the surface. ... Seems to me that if we splice in Ned's tweaked privacy language, we're done. I don't see any reason to change

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

On Wed, Dec 23, 2020 at 4:52 PM Murray S. Kucherawy wrote: > On Wed, Dec 23, 2020 at 12:08 PM John R Levine wrote: > >> > Failing that, I have another proposal to consider that might aid us in >> > shipping a standards track DMARC sooner: Remove any and all mention of >> > failure reports, and

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

On Wed, Dec 23, 2020 at 12:08 PM John R Levine wrote: > > Failing that, I have another proposal to consider that might aid us in > > shipping a standards track DMARC sooner: Remove any and all mention of > > failure reports, and do all that in a later add-on document as was done > > with RFC

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

> On Wed, Dec 23, 2020 at 10:10 AM John R Levine wrote: > > On Wed, 23 Dec 2020, Ned Freed wrote: > > > Failure reports provide detailed information about the failure of a > > single > > > message or a group of similar messages failing for the same reason. They > > > are meant to aid in cases

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

Modulo a couple of tweaks (below), I agree. Tweaks: * s/whether or not/whether/ * s/decoding/deciding/ Sure. Now ship it? Failing that, I have another proposal to consider that might aid us in shipping a standards track DMARC sooner: Remove any and all mention of failure reports, and do all

  1   2   >