subject:"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 of what they actually 
wrote to explain your rather divergent interpretation of it.


d/



___
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

2021-01-06 Thread Dave Crocker


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.


d/

--
Dave Crocker
dcroc...@gmail.com
408.329.0791

Volunteer, Silicon Valley Chapter
American Red Cross
dave.crock...@redcross.org

___
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

2021-01-06 Thread Dave Crocker


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 experience, but 
DomainKeys had gone through two rounds of field deployment.  So, 
arguably, she was being kind about IIM.


The issue isn't what was in your head but what was in the field 
experience of the industry.


d/

--
Dave Crocker
dcroc...@gmail.com
408.329.0791

Volunteer, Silicon Valley Chapter
American Red Cross
dave.crock...@redcross.org

___
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

2021-01-06 Thread Murray S. Kucherawy

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 we were doing things based on opinion and conjecture. It
> did not take 16 years for there to be data. There was data before DK and
> IIM were merged to form DKIM.
>
> What data? Data that showed what? That's completely news to me. You
> weren't even part of the informal group who caused DKIM to be created, iirc.
>
Everyone,

A working group charter is in some sense a contract between the IESG and
the working group regarding what work it will do, how it will do it, and
what its deliverables are.

I hope it's clear that the discussion taking place here does nothing in
service of that contract.

Please get yourselves back on track without undue delay.

-MSK, your increasingly irritable Area Director
___
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 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 biggest change for the better was senders closing open 
relays. It's still not clear that DKIM had any affect on that.


Mike


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 we were doing things based on opinion and 
conjecture. It did not take 16 years for there to be data. There was 
data before DK and IIM were merged to form DKIM.


What data? Data that showed what? That's completely news to me. You 
weren't even part of the informal group who caused DKIM to be created, iirc.


Mike

___
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

2021-01-06 Thread Dotzero

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 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 at as a heresy. DKIM itself was a leap of faith.
>>> 16 years later it is gratifying that we have data.
>>>
>>> Mike
>>>
>>
>> DKIM was NOT a leap of faith. At the time there was plenty of data from
>> DK (Domain Keys) and IIM to inform those involved. Please stop making
>> assertions of "fact" which are simply not true.
>>
>> 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.
>>
>> Mike
>>
>
> So all the data was in your head? I wasn't using IIM but was publishing DK
> and getting feedback from Yahoo! and a few other receivers through private
> channels. There were other senders in a similar situation as myself. And
> yes, people were discussing things privately (Web of Trust groups). Your
> claim that there was no data available at the time is quite simply false.
>
> 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 biggest change for the better was
> senders closing open relays. It's still not clear that DKIM had any affect
> on that.
>
> Mike
>

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 we were doing things based on opinion and conjecture. It did not
take 16 years for there to be data. There was data before DK and IIM were
merged to form DKIM.

Michael Hammer
___
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 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 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 at as a heresy. DKIM itself was a leap
of faith.
16 years later it is gratifying that we have data.

Mike


DKIM was NOT a leap of faith. At the time there was plenty of
data from DK (Domain Keys) and IIM to inform those involved.
Please stop making assertions of "fact" which are simply not true.


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.

Mike


So all the data was in your head? I wasn't using IIM but was 
publishing DK and getting feedback from Yahoo! and a few other 
receivers through private channels. There were other senders in a 
similar situation as myself. And yes, people were discussing things 
privately (Web of Trust groups). Your claim that there was no data 
available at the time is quite simply false.


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 biggest change for the 
better was senders closing open relays. It's still not clear that DKIM 
had any affect on that.


Mike

___
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

2021-01-06 Thread Dotzero

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 conjecture. It would
>> be good for it to be required reading for everybody on this working
>> group, and not snarled at as a heresy. DKIM itself was a leap of faith.
>> 16 years later it is gratifying that we have data.
>>
>> Mike
>>
>
> DKIM was NOT a leap of faith. At the time there was plenty of data from DK
> (Domain Keys) and IIM to inform those involved. Please stop making
> assertions of "fact" which are simply not true.
>
> 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.
>
> Mike
>

So all the data was in your head? I wasn't using IIM but was publishing DK
and getting feedback from Yahoo! and a few other receivers through private
channels. There were other senders in a similar situation as myself. And
yes, people were discussing things privately (Web of Trust groups). Your
claim that there was no data available at the time is quite simply false.

Michael Hammer
___
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 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 to be required reading for everybody on this working
group, and not snarled at as a heresy. DKIM itself was a leap of
faith.
16 years later it is gratifying that we have data.

Mike


DKIM was NOT a leap of faith. At the time there was plenty of data 
from DK (Domain Keys) and IIM to inform those involved. Please stop 
making assertions of "fact" which are simply not true.


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.


Mike

___
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

2021-01-05 Thread Dotzero

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 at as a heresy. DKIM itself was a leap of faith.
> 16 years later it is gratifying that we have data.
>
> Mike
>

DKIM was NOT a leap of faith. At the time there was plenty of data from DK
(Domain Keys) and IIM to inform those involved. Please stop making
assertions of "fact" which are simply not true.

Michael Hammer
___
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 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

___
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 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
dave.crock...@redcross.org

___
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 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 introduce new information 
or re-ignite this fight.  The chairs and our charter call for us to 
proceed with DMARC as a tool to control misuse of the From address, 
which is also what I want.



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 at as a heresy. DKIM itself was a leap of faith. 
16 years later it is gratifying that we have data.


Mike

___
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

2021-01-05 Thread Douglas Foster

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
fight.  The chairs and our charter call for us to proceed with DMARC as a
tool to control misuse of the From address, which is also what I want.

To that end, we want to make sender, intermediary, and forwarder interests
converge as much as possible.Our strategy is for intermediaries to
provide sufficient information for an evaluator to fairly judge whether a
particular message is in his interests or contrary to them.   By my
analysis, we are not there yet.

The particular information that I seek to achieve this result is the
following:
(a) know whether forwarding action(s) have occurred during transit
(b) reconstruct the message identity state prior to the forward(s), so I
can evaluate the message based on both the intermediate and final message
states.

I cannot reconstruct prior state using most ARC sets, because ARC only
provides an identifier if that identifier was evaluated.  Even then, some
of the identifiers are provided in comments or not at all.   Evaluating the
message based on its prior state requires a complete set of identifiers.

DF
___
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 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 accurately representing what 
I said or what the study shows.  Attention to detail will help.  
Conclusions are less important than showing your work.


d/

--
Dave Crocker
dcroc...@gmail.com
408.329.0791

Volunteer, Silicon Valley Chapter
American Red Cross
dave.crock...@redcross.org

___
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 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 user-oriented mechanism. Web vs. email.  Why and how does that 
make a difference?


The extensive experience with the web EV experiment has been that it 
does NOT make a difference.  Since you seem to dismiss this web 
experience, please explain why it is not relevant to the current topic.


I'm dismissing nothing. That is a strawman. I already said why its 
problematic to compare the two which apparently you did dismissing and 
why it's preferable to have an apples-apples comparison.


The study was directly about email. If you read it, the authors were 
also skeptical about the efficacy.


Exactly.  Thank you for noting that.  But, then, it raises the 
question of why you cited it as demonstrating meaningful efficacy for 
signalling DMARC results to end users?


Quit cutting out needed context to make your points. The study directly 
contradicts your categorical statement. Your issue is with the study's 
authors not me. Quit shooting the messenger.


Mike, this is just silly. and typical. I'm done.

___
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 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 and how does that make 
a difference?


The extensive experience with the web EV experiment has been that it 
does NOT make a difference.  Since you seem to dismiss this web 
experience, please explain why it is not relevant to the current topic.



The study was directly about email. If you read it, the authors were 
also skeptical about the efficacy.


Exactly.  Thank you for noting that.  But, then, it raises the question 
of why you cited it as demonstrating meaningful efficacy for signalling 
DMARC results to end users?



d/

--

Dave Crocker
dcroc...@gmail.com
408.329.0791

Volunteer, Silicon Valley Chapter
American Red Cross
dave.crock...@redcross.org

___
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 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 isn't 
especially a good example because the situations are not the same. At 
least this study is directly relevant and it doesn't support your 
categorical statement. This is actually a Good Thing.


Oh?  A trust indicator to a user, flagging a domain name, isn't pretty 
much the same?  Please explain.


Pretty much != same. The study was directly about email. If you read it, 
the authors were also skeptical about the efficacy. It sounds like you 
have an issue with the study, not me. Maybe you should take it up with 
them and we can be done. In the mean time, I'll take hard data over your 
speculation.


Mike

___
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



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 situations are not the same. At 
least this study is directly relevant and it doesn't support your 
categorical statement. This is actually a Good Thing.


Oh?  A trust indicator to a user, flagging a domain name, isn't pretty 
much the same?  Please explain.



At least this study is directly relevant and it doesn't support your 
categorical statement. This is actually a Good Thing.


It is largely unrelated to my observation about efficacy of trust 
indicators for average users..



I did provide it with that paper. You seem to be dismissing it out of 
hand in favor of something that isn't even email based. We are here 
because of email, so I think that's pretty relevant.


Except that I didn't 'dismiss' it, out of hand or otherwise.



You really should read the paper.

Your implication that I haven't is both odd and troublesome.
In 15 minutes? It's like 30 pages long and very technical. And you're 
asking me whether I read it closely? If you have read it before, just 
say that. If you haven't you can skip to the part that doesn't support 
your categorical statement.


sigh.


d/


--
Dave Crocker
dcroc...@gmail.com
408.329.0791

Volunteer, Silicon Valley Chapter
American Red Cross
dave.crock...@redcross.org

___
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 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 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." The word 
all includes human beings. That's the nature of "all".

1. In terms of average use for typical email, it is.
What study asserts that for email? You wouldn't take my word for it 
if I said that. But of course I wouldn't make a categorical statement 
without empirical evidence.


You seem to be seeing a requirement to prove the negative, while the 
actual requirement is to prove the positive.  A claim that there is 
meaningful efficacy, for average recipients, by having visual trust 
indicators, requires affirmative demonstration that there is.  There 
is no requirement to prove there isn't.  My point is that we have 
decades of belief that it's useful but no demonstration that it 
actually is.  And we have history such as the EV effort, showing that 
it isn't.


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 situations are not the same. At 
least this study is directly relevant and it doesn't support your 
categorical statement. This is actually a Good Thing.


I did provide it with that paper. You seem to be dismissing it out of 
hand in favor of something that isn't even email based. We are here 
because of email, so I think that's pretty relevant.





You really should read the paper.


Your implication that I haven't is both odd and troublesome.

In 15 minutes? It's like 30 pages long and very technical. And you're 
asking me whether I read it closely? If you have read it before, just 
say that. If you haven't you can skip to the part that doesn't support 
your categorical statement.


Mike

___
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 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 anything is not correct.

I didn't say that.  And it didn't say that.
"Also, receiver filtering engines are all that matter." The word all 
includes human beings. That's the nature of "all".

1. In terms of average use for typical email, it is.
What study asserts that for email? You wouldn't take my word for it if 
I said that. But of course I wouldn't make a categorical statement 
without empirical evidence.


You seem to be seeing a requirement to prove the negative, while the 
actual requirement is to prove the positive.  A claim that there is 
meaningful efficacy, for average recipients, by having visual trust 
indicators, requires affirmative demonstration that there is.  There is 
no requirement to prove there isn't.  My point is that we have decades 
of belief that it's useful but no demonstration that it actually is.  
And we have history such as the EV effort, showing that it isn't.


Your focus on email, as somehow distinctive, would need some basis for 
ignoring the web experience.  Feel free to provide it.




You really should read the paper.


Your implication that I haven't is both odd and troublesome.


d/

--

Dave Crocker
dcroc...@gmail.com
408.329.0791

Volunteer, Silicon Valley Chapter
American Red Cross
dave.crock...@redcross.org

___
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 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.  And it didn't say that.
"Also, receiver filtering engines are all that matter." The word all 
includes human beings. That's the nature of "all".


1. In terms of average use for typical email, it is.

What study asserts that for email? You wouldn't take my word for it if I 
said that. But of course I wouldn't make a categorical statement without 
empirical evidence.


You really should read the paper. It's quite clever what they did, and 
provides a lot of interesting information to consider. It was very 
interesting to see what was happening in the wild instead of the 
conjecture that informs most of what goes on. They apparently have a 
follow on study they're working on.


Mike

___
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 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 filtering engines are all that matter." The word all 
includes human beings. That's the nature of "all".


1. In terms of average use for typical email, it is.

2. The quoted statement has no semantic relationship to what you claimed 
I asserted (above).




And you are wildly off topic.


'we' might be. but note that I'm merely responding to your own content.


d/


--
Dave Crocker
dcroc...@gmail.com
408.329.0791

Volunteer, Silicon Valley Chapter
American Red Cross
dave.crock...@redcross.org

___
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 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." The word all 
includes human beings. That's the nature of "all".


And you are wildly off topic.

Mike

___
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 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 Red Cross
dave.crock...@redcross.org

___
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 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 definitive about much of anything.

https://www.usenix.org/system/files/conference/usenixsecurity18/sec18-hu.pdf 




thanks.

How carefully did you read the details?  While I suppose the study is 
a bit interesting, it's a very long way from serving as definitive 
'proof' of much of anything.


Who said it was proof? It's data. Very useful data, IMO. Did you read it 
carefully? It took me about a day to digest it. It also says with actual 
data that your assertion that users can't be trusted for anything is not 
correct. Categorical statements without data are always dubious.


Mike

___
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 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.


https://www.usenix.org/system/files/conference/usenixsecurity18/sec18-hu.pdf


thanks.

How carefully did you read the details?  While I suppose the study is a 
bit interesting, it's a very long way from serving as definitive 'proof' 
of much of anything.



Actual data, actual experiments. Finally. And it's a lot better than 
all of the conjecture here which is the currency of the realm.


You might want to review the actual semantics of the statistical methods 
used for actual experiments.  They don't mean what you seem to think 
they mean. In particular note that the focus of such semantics is on 
negatives, rather than positives.  It's the reason that conclusions 
about affirmative statements require a constellation of studies.



I use my inner Luddite to use all of the time. It's one of my skills. 
But an MUA designed with security in mind with its UI would go a long 
way too. From re-writing is exactly the wrong thing to do from a 
security standpoint though.


That's been a regular refrain, for decades. Odd that we do not yet see 
actual efficacy, after all that... conjecture.


By now, there should be that constellation of compelling evidence for 
the efficacy of visual indicators with average recipients.



d/

--
Dave Crocker
dcroc...@gmail.com
408.329.0791

Volunteer, Silicon Valley Chapter
American Red Cross
dave.crock...@redcross.org

___
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 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.  Real-time actions by 
recipients are demonstrably irrelevant to DMARC (and all other 
anti-abuse) utility.


That's not the conclusion of the paper that Doug Foster linked to the 
other day.



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.


https://www.usenix.org/system/files/conference/usenixsecurity18/sec18-hu.pdf

Actual data, actual experiments. Finally. And it's a lot better than all 
of the conjecture here which is the currency of the realm.



When I first came back and saw the From rewriting I was very confused 
by what it was until I figured out what was going on.


You think you are representative of end users?  Try again.


I use my inner Luddite to use all of the time. It's one of my skills. 
But an MUA designed with security in mind with its UI would go a long 
way too. From re-writing is exactly the wrong thing to do from a 
security standpoint though.


Mike

___
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 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 demonstrably irrelevant to DMARC (and all other 
anti-abuse) utility.


That's not the conclusion of the paper that Doug Foster linked to the 
other day.



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.

3. Especially when it counters years of experience, including the Web EV 
experiment:


https://en.wikipedia.org/wiki/Extended_Validation_Certificate



  Effectiveness against phishing attacks with IE7 security UI

In 2006, researchers at Stanford University 
 and Microsoft 
Research  conducted 
a usability study^[21] 
 
of the EV display in Internet Explorer 7 
. Their paper 
concluded that "participants who received no training in browser 
security features did not notice the extended validation indicator and 
did not outperform the control group", whereas "participants who were 
asked to read the Internet Explorer help file were more likely to 
classify both real and fake sites as legitimate". 



When I first came back and saw the From rewriting I was very confused 
by what it was until I figured out what was going on. 


You think you are representative of end users?  Try again.


d/

--
Dave Crocker
dcroc...@gmail.com
408.329.0791

Volunteer, Silicon Valley Chapter
American Red Cross
dave.crock...@redcross.org

___
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 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 other 
anti-abuse) utility.


That's not the conclusion of the paper that Doug Foster linked to the 
other day. It showed that visual indicators statistically helped. The 
biggest problem was the low deployment rate of DMARC from what I can 
tell from the paper. Everybody here should read that paper IMO.


When I first came back and saw the From rewriting I was very confused by 
what it was until I figured out what was going on. If it were directly 
sent to me I would definitely be suspicious. But Thunderbird shows the 
entire email address when you view it, unlike some of the crappy MUA's 
out there. What we should be agitating for is better MUA's in general 
that care about security. Not IETF, obviously, but the email community 
at large.


Mike

___
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

2021-01-05 Thread Paypal security confirm your password now

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 the
> original domain.

I think you're saying that I can always evade DMARC problems by
putting an
address I control on the From line and nobody will notice.  That
would
mean that DMARC is useless.

If that's not what you're saying, could you clarify?

That is indeed the assertion - as long as you consider 97+% to be 
"always" and interpret "nobody" in terms of real human actors 
(excluding the automatons on this list) and discount the influence of 
receiver-level reputation/filtering mechanisms. Personally, I think 
those levels of rounding errors should not be ignored either for good 
or evil. The formation of this working group and our initial 
deliverables provides some level of concurrence with my personal 
perspective.

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 other anti-abuse) utility.

DMARC has utility because a great deal of spam includes unauthorized use 
of domain names that happen to support DMARC.

Some anti-abuse methods have inherent utility.  They are useful even if 
abusers seek to defeat the methods.  Other methods have utility by 
virtue of correlations with current behavior.  They are useful now, but 
merely require some effort by abusers to defeat (or route around.)

DMARC has the appearance of the former but is actually the latter.

d/

--
Dave Crocker
dcroc...@gmail.com
408.329.0791

Volunteer, Silicon Valley Chapter
American Red Cross
dave.crock...@redcross.org

___
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

2021-01-05 Thread Jim Fenton




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 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 the original domain.


I think you're saying that I can always evade DMARC problems by 
putting an address I control on the From line and nobody will notice.  
That would mean that DMARC is useless.


If that's not what you're saying, could you clarify?


I used the word “often” and indeed some people will notice as I did. 
But I recall we beat this issue to death a few months ago, although 
I’m not sure what WG consensus on that was, if any.


It looks like we’ve strayed pretty far from the subject line (failure 
reports) though.


-Jim

___
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

2021-01-05 Thread Kurt Andersen (b)

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 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 the
> > original domain.
>
> I think you're saying that I can always evade DMARC problems by putting an
> address I control on the From line and nobody will notice.  That would
> mean that DMARC is useless.
>
> If that's not what you're saying, could you clarify?
>

That is indeed the assertion - as long as you consider 97+% to be "always"
and interpret "nobody" in terms of real human actors (excluding the
automatons on this list) and discount the influence of receiver-level
reputation/filtering mechanisms. Personally, I think those levels of
rounding errors should not be ignored either for good or evil. The
formation of this working group and our initial deliverables provides some
level of concurrence with my personal perspective.

--Kurt
___
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


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 exist. OTOH, getting 
alignment avoids a restrictive policy that might be associated with the 
original domain.


I think you're saying that I can always evade DMARC problems by putting an 
address I control on the From line and nobody will notice.  That would 
mean that DMARC is useless.


If that's not what you're saying, could you clarify?

Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly___
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

2021-01-05 Thread Jim Fenton


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 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 the original domain.


-Jim

___
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

2021-01-04 Thread Douglas Foster

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 the client identity, so I
do not fear spoofing, even from ESPs that happily provide their services to
criminal domains.  Those that serve criminals have all of their
unclassified clients sent to administrative quarantine.  A small portion
that is found to be wanted traffic will be released and exempted from
quarantine on future messages.

If the same messages were received indirectly, it would be a problem
because the SMTP rewrite hides the ESP identity, so the quarantine would
not happen.  Hence, I must start scanning the entire Received chain and
related headers.

Since everyone deals with the same ESPs, I think everyone needs to do full
scans also.

DF


On Mon, Jan 4, 2021, 2:24 PM Alessandro Vesely  wrote:

> 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, the interest of the user's
> network, or
> >>> the policies of the user's organization."   Perhaps this is too
> >>> restrictive, because it  excludes advertising which is harmless in its
> >>> intent but unwanted by the recipient.
> >>
> >> Having advertisements come /From: advertiser/ is a goal.
> >
> > Yes.
> >
> > [snip]
> >
> >>> Email evaluation products need to handle all possible scenarios.  This
> >>> includes
> >>> - forwarded and not forwarded
> >>> - with and without SMTP rewrite
> >>> - with and without modification.
> >>> - with and without From rewrite
> >>> - with and without ARC sets
> >>> - whether the email header chain is accurately documented or
> fraudulently fabricated.
> >>
> >> Girl Scout troops will inevitably fall in the not forwarded category.
> ESP messages, instead, should come /From: ESP/.
> >
> > This incompatible with the above goal of having advertisements come from
> the advertiser.
>
>
> That depends on how you define "advertiser".  If you entrust your
> communication to an external agent, the advertiser becomes that.  Maybe, an
> agent they could differentiate by using subdomains, similar to the "
> onmicrosoft.com" suffix.
>
>
> > I find it highly problematic that we’re teaching recipients that they
> get official mail from companies that come from an address that is not
> connected to the company at all. It further devalues the 5322.from and
> means that recipients cannot trust the domains that the see there. This is
> even more true when the domain is one they’ve never heard of and passes all
> of the checks and comes in with a ‘verified by DMARC.’
>
>
> Agreed.
>
> A recipient should somehow trust the ESP, or else discard their messages.
>
> Then, there are several ways that an ESP (or a MLM) can try and convey
> some kind of transparency of intents.  One can use subdomains and display
> names.  IMHO, we should add some guidelines about this in the spec.
>
> Of course, publishing the ESP's selectors would complete the entrust
> better.  The scalability looks similar to that of subscribed feedback loops.
>
> (Managing communication internally is even better.)
>
>
> > 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 the
> domain being phished.
>
>
> We cannot prevent phishers from doing so anyway.  Yet, if we insist on
> using DMARC nevertheless, authentication will create "a noise-free basis
> for developing an indentifier's reputation", in Dave's words.
>
>
> > This seems to me to be a step along the path of making DMARC irrelevant
> by teaching recipients that mail with a 5322.from address they don’t
> recognize is legitimate email.
>
>
> It is as legitimate as the identifier's reputation.
>
>
> Best
> Ale
> --
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> ___
> 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

2021-01-04 Thread Alessandro Vesely

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, the interest of the user's network, or
the policies of the user's organization." Perhaps this is too
restrictive, because it excludes advertising which is harmless in its
intent but unwanted by the recipient.

Having advertisements come /From: advertiser/ is a goal.

Yes.

[snip]

Email evaluation products need to handle all possible scenarios. This
includes
- forwarded and not forwarded
- with and without SMTP rewrite
- with and without modification.
- with and without From rewrite
- with and without ARC sets
- whether the email header chain is accurately documented or fraudulently
fabricated.

Girl Scout troops will inevitably fall in the not forwarded category. ESP
messages, instead, should come /From: ESP/.

This incompatible with the above goal of having advertisements come from the
advertiser.

That depends on how you define "advertiser". If you entrust your communication to an
external agent, the advertiser becomes that. Maybe, an agent they could differentiate by using
subdomains, similar to the "onmicrosoft.com" suffix.

I find it highly problematic that we’re teaching recipients that they get
official mail from companies that come from an address that is not connected to
the company at all. It further devalues the 5322.from and means that recipients
cannot trust the domains that the see there. This is even more true when the
domain is one they’ve never heard of and passes all of the checks and comes in
with a ‘verified by DMARC.’

Agreed.

A recipient should somehow trust the ESP, or else discard their messages.

Then, there are several ways that an ESP (or a MLM) can try and convey some
kind of transparency of intents. One can use subdomains and display names.
IMHO, we should add some guidelines about this in the spec.

Of course, publishing the ESP's selectors would complete the entrust better.
The scalability looks similar to that of subscribed feedback loops.

(Managing communication internally is even better.)

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 the domain being
phished.

We cannot prevent phishers from doing so anyway. Yet, if we insist on using DMARC
nevertheless, authentication will create "a noise-free basis for developing an
indentifier's reputation", in Dave's words.

This seems to me to be a step along the path of making DMARC irrelevant by
teaching recipients that mail with a 5322.from address they don’t recognize is
legitimate email.

It is as legitimate as the identifier's reputation.

Best
Ale
--

___
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

2021-01-04 Thread Michael Thomas




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 know anything about the originating domain if they 
have a p=reject policy to do as they suggest. For many domains and 
especially commercial domains that is probably exactly the right thing 
to do.


Mike

___
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

2021-01-04 Thread Dave Crocker





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 responsible for that identifier.



d/

--
Dave Crocker
dcroc...@gmail.com
408.329.0791

Volunteer, Silicon Valley Chapter
American Red Cross
dave.crock...@redcross.org

___
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

2021-01-04 Thread John Levine

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 the 
>domain being phished. 
>
>This seems to me to be a step along the path of making DMARC irrelevant by 
>teaching recipients that mail with a 5322.from address they don’t
>recognize is legitimate email. 

We went through this same argument with DKIM 15 years ago, explaining
over and over to people who imagined that DKIM was a magic whitelist
bullet that a DKIM signature by itself tells you nothing. It's only
useful if you know something, good or bad, about the domain.

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.

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

2021-01-04 Thread Laura Atkins

> 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
>> the policies of the user's organization."   Perhaps this is too
>> restrictive, because it  excludes advertising which is harmless in its
>> intent but unwanted by the recipient.
> 
> 
> Having advertisements come /From: advertiser/ is a goal.

Yes. 

[snip]

>> Email evaluation products need to handle all possible scenarios.  This
>> includes
>> - forwarded and not forwarded
>> - with and without SMTP rewrite
>> - with and without modification.
>> - with and without From rewrite
>> - with and without ARC sets
>> - whether the email header chain is accurately documented or fraudulently 
>> fabricated.
> 
> Girl Scout troops will inevitably fall in the not forwarded category.  ESP 
> messages, instead, should come /From: ESP/.

This incompatible with the above goal of having advertisements come from the 
advertiser. 

I find it highly problematic that we’re teaching recipients that they get 
official mail from companies that come from an address that is not connected to 
the company at all. It further devalues the 5322.from and means that recipients 
cannot trust the domains that the see there. This is even more true when the 
domain is one they’ve never heard of and passes all of the checks and comes in 
with a ‘verified by DMARC.’ 

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 the domain being 
phished. 

This seems to me to be a step along the path of making DMARC irrelevant by 
teaching recipients that mail with a 5322.from address they don’t recognize is 
legitimate email. 

laura 

-- 
Having an Email Crisis?  We can help! 800 823-9674 

Laura Atkins
Word to the Wise
la...@wordtothewise.com
(650) 437-0741  

Email Delivery Blog: https://wordtothewise.com/blog 

___
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

2021-01-04 Thread Alessandro Vesely


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?



I'd add the whole "Sending side workarounds", mostly as-is, but edited as 
needed.


If it's anything like telling mailing lists how to rewrite From lines, the 
answer is no.  That's way out of scope.



Why?  I read:

The working group will specify mechanisms for reducing or eliminating
the DMARC's effects on indirect mail flows, including deployed
behaviors of many different intermediaries, such as mailing list
managers, automated mailbox forwarding services, and MTAs that
perform enhanced message handling that results in message
modification. Among the choices for addressing these issues are:

(which can hardly be considered fully completed with just ARC), and:

The working group will document operational practices in terms of
configuration, installation, monitoring, diagnosis and reporting. It
will catalog currently prevailing guidelines as well as developing
advice on practices that are not yet well-established but which are
believed to be appropriate.

Isn't From: rewriting an operational practice?  It is not so important to tell 
MLMs how to do, since they already seem to do a good job, as it is to tell 
ESPs, which, as you say, don't.




PS: 10.5



Eh?

10.5.  DMARC Report Format Registry?
Mac OS X 10.5 Leopard?
Magnitude 10.5?

What did you mean?


Best
Ale
--








___
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

2021-01-04 Thread Alessandro Vesely


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 DMARC to situations where it does not work.



Let me object to the consistency of this point of view.  Unlike PGP, DMARC is 
not designed as an end-to-end protocol.  The only way that a user could decide 
on a per-message basis whether or not her message should be subject to which 
policy would be to have a variety of domains configured with each policy and 
then set her From: header field appropriately.  Clearly not a viable mode of 
operation.


A general purpose domain can have email users and some transactional mail as 
well.  DMARC has to be configured to suite all of them.  There are special 
domains, which are highly abused.  They had to direct their users to use 
subdomains for non-transactional mail.  The need to do so can be considered a 
DMARC defect, IMHO.




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
the policies of the user's organization."   Perhaps this is too
restrictive, because it  excludes advertising which is harmless in its
intent but unwanted by the recipient.



Having advertisements come /From: advertiser/ is a goal.



What is clear is that by this definition, mailing list messages are
legitimate, and yet are incompatible with DMARC.



No, MLM messages with rewritten From: are fully compatible.



Similarly, messages which are tagged with informational content by a spam
filter and then forwarded at the request of the primary recipient are also
legitimate.


Not sure.  Spam shouldn't be forwarded.



In both cases, specific messages may be unwanted or hostile, but the class
of messages is wanted. >
My exception language is still incomplete, because we have another class of
senders who ignore DMARC but are too important to block.My list in that
category includes a U.S. government agency and two vendors of cloud-based
products for secure web relay.

We need to set appropriate expectations for product developers, email
gateway operators, and domain owners.Otherwise we end up with wrong
assumptions which lead to products which mindlessly apply a disposition
without providing adequate exception mechanisms.



It is much simpler if the sender is DMARC-aware and sends messages that pass 
DMARC.  There is a plethora of legacy devices and servers that send plain old 
mail.  They are a problem and need to be identified and somehow gatewayed or 
delivered skipping DMARC processing.




Address rewriting is NOT the optimal answer to the problem, because it
hides the forwarding operation without addressing the complications that
forwarding creates for correctly evaluating email reputation.



Hiding depends on how you rewrite and forward.  Receivers can examine ARC 
chains and/or undo MLM transformations so as to deliver a fully meaningful 
message header.




Email evaluation products need to handle all possible scenarios.  This
includes
- forwarded and not forwarded
- with and without SMTP rewrite
- with and without modification.
- with and without From rewrite
- with and without ARC sets
- whether the email header chain is accurately documented or fraudulently 
fabricated.



Girl Scout troops will inevitably fall in the not forwarded category.  ESP 
messages, instead, should come /From: ESP/.




The only way to handle all of these scenarios is for the email filter to
examine the entire chain of Received headers and other headers.   There is
no simple algorithm for performing this analysis.   There is an opportunity
for IETF to provide ways for legitimate MTAs to facilitate this process,
and ARC is a step in the right direction, but only a first step.



I wish it ends up in something deterministic that can be used by small and 
large providers alike.




We may be able to promote DMARC adoption by overselling its capabilities,
but I do not see that as a good thing.



Some people push for domains to migrate toward a strict policy.  They assume 
that p=none is a transitory status.  I wouldn't call that "overselling", as, in 
fact, having p=none currently provides the best deliverability.  Yet, p=none 
makes DMARC non-actionable, which I think is a limitation.



Best
Ale
--

























___
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

2021-01-03 Thread Douglas Foster

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 "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
the policies of the user's organization."   Perhaps this is too
restrictive, because it  excludes advertising which is harmless in its
intent but unwanted by the recipient.

What is clear is that by this definition, mailing list messages are
legitimate, and yet are incompatible with DMARC.  Similarly, messages which
are tagged with informational content by a spam filter and then forwarded
at the request of the primary recipient are also legitimate.  In both
cases, specific messages may be unwanted or hostile, but the class of
messages is wanted.

My exception language is still incomplete, because we have another class of
senders who ignore DMARC but are too important to block.My list in that
category includes a U.S. government agency and two vendors of cloud-based
products for secure web relay.

We need to set appropriate expectations for product developers, email
gateway operators, and domain owners.Otherwise we end up with wrong
assumptions which lead to products which mindlessly apply a disposition
without providing adequate exception mechanisms.

Address rewriting is NOT the optimal answer to the problem, because it
hides the forwarding operation without addressing the complications that
forwarding creates for correctly evaluating email reputation.

Email evaluation products need to handle all possible scenarios.  This
includes
- forwarded and not forwarded
- with and without SMTP rewrite
- with and without modification.
- with and without From rewrite
- with and without ARC sets
- whether the email header chain is accurately documented or fraudulently
fabricated.

The only way to handle all of these scenarios is for the email filter to
examine the entire chain of Received headers and other headers.   There is
no simple algorithm for performing this analysis.   There is an opportunity
for IETF to provide ways for legitimate MTAs to facilitate this process,
and ARC is a step in the right direction, but only a first step.

We may be able to promote DMARC adoption by overselling its capabilities,
but I do not see that as a good thing.

DF

On Sun, Jan 3, 2021 at 7:48 AM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:

> But we do not have a comprehensive protocol, so we need to set appropriate
> expectations.
>
> I will 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 the policies of the user's organization."
>
> Either mailing list messages, as a class are legitimate, or not -- and we
> have concluded that they are.   (Indvidual messages could be in either
> category.)Messages that are tagged by a spam filter and then forwarded
> to the recipients alternate mailbox are also legitimate.  We need to set
> appropriate expectations for product developers, email gateway operators,
> and domain owners. My exception language is actually still incomplete,
> because we have the category of senders who ignore DMARC but are too
> important to block.My list in that category includes a U.S. government
> agency and two vendors of cloud-based email filtering software.
>
> DMARC FAIL can at best provide a data point for a filtering algorithm, as
> was stated in my interchange with Todd.   Claiming more than that will only
> result in misuse of DMARC concepts.
>
> There are real security issues to consider with forwarded mail.   Address
> rewriting hides some of them without solving the problems.   We need an
> in-depth assessment of how to evaluate forwarded mail.   Is this group the
> one to do it or is it assigned somewhere else?
>
> Doug Foster
>
> On Sun, Jan 3, 2021 at 5:50 AM Alessandro Vesely  wrote:
>
>> 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 rejected.  These are discussed in Section 9.
>> >
>> > I suggest replacing it with a scope statement, such as this:
>> >
>> > DMARC checks are applicable when a message is received directly from
>> > the domain owner, or received indirectly from a mediator without
>> > in-transit modification.  As discussed in Section 9, these two
>> > criteria do not cover all legitimate email flows.

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

2021-01-03 Thread John R Levine


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 From lines, 
the answer is no.  That's way out of scope.


Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

PS: 10.5

___
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

2021-01-03 Thread Alessandro Vesely


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 stasis 
forevermore. If the scouts email breaks, they can get somebody to fix it. They 
will thank us in the long run when scammers can't phish using them as a prop.


I agree too. I'm pretty sure there are more small organizations using
provider e-mail addresses than little private mail servers sending
less than 1000 messages a day, so let's declare both of those out of
scope. Or maybe not.
[...]

PS: This really is off in the weeds, isn't it?



I don't think so.  There is a very practical outcome.  We should expand Section 
9.5, "Interoperability Issues" and say something actually workable.  And its 
referring to Section 5.2 of RFC 6377, "DKIM Author Domain Signing Practices", 
has done its time and can be dropped.


I recall that MLMs were involved in a discussion about DMARC mitigation 
here[*], before From: rewriting started to take root.  Perhaps, things happened 
that way because, after all, IETF's own mailing lists were affected. 
Conversely, we never addressed the Girls Scout troops problem.


Now, MLMs work well even though From: rewriting isn't standardized yet, while 
ESPs apparently didn't get that hint.  Therefore we should describe From: 
rewriting (and possibly some other workarounds of those) in Section 9.5 of 
dmarcbis, so that everybody knows.  BTW, that's our chance to say /how/ to 
rewrite From:.


We should also encourage large free-mailbox providers to publish selectors with 
trusted ESPs' public keys.  Unlike MLM transformations, ESP messages cannot be 
authenticated by other means.



Best
Ale
--

[*] dmarc-ietf] IETF Mailing Lists and DMARC
Cullen Jennings, Wed, 02 November 2016 16:00 UTC
https://mailarchive.ietf.org/arch/msg/dmarc/2uVZ0BVpGoXSviXZxhU-G0sDSNc/




















___
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

2021-01-03 Thread Alessandro Vesely


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 rejected.  These are discussed in Section 9.

I suggest replacing it with a scope statement, such as this:

DMARC checks are applicable when a message is received directly from
the domain owner, or received indirectly from a mediator without
in-transit modification.  As discussed in Section 9, these two
criteria do not cover all legitimate email flows.   When a message is
received indirectly with modification, DMARC cannot produce a usable
result, and the message should be evaluated using alternate criteria.
  When messages may have been forwarded with modifications, the
algorithm for distinguishing between authorized and unauthorized
messages becomes difficult to define.



I disagree.  Limiting the applicability of DMARC is not going to boost its 
actionable usage.  The above wording boils down to suggesting a sequence of 
operations as follows:


1:  check SPF.  If not pass then the message is indirect.

2:  check DKIM.  If not pass then the message is with modification.  Hence 
DMARC results are not usable.



That would nullify the whole protocol.


Best
Ale
--




















___
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

2021-01-02 Thread Dave Crocker




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, as well as failing to consider more general 
application of the 'logic'.


Email (and most other online) security has a sufficiently poor record so 
that claims about what is essential to do -- absent compellingly 
validated, reliable, and precise data -- has nothing at all with what is 
essential to do and everything to do with avoiding serious discussion.



d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

___
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

2021-01-02 Thread Douglas Foster

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 replacing it with a scope statement, such as this:

DMARC checks are applicable when a message is received directly from
the domain owner, or received indirectly from a mediator without
in-transit modification.  As discussed in Section 9, these two
criteria do not cover all legitimate email flows.   When a message is
received indirectly with modification, DMARC cannot produce a usable
result, and the message should be evaluated using alternate criteria.
 When messages may have been forwarded with modifications, the
algorithm for distinguishing between authorized and unauthorized
messages becomes difficult to define.

On Thu, Dec 31, 2020 at 12:51 PM 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 only address the scout troop has?
>
> Regards,
> John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
> Please consider the environment before reading this e-mail. https://jl.ly
>
> ___
> 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

2021-01-02 Thread John Levine

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 breaks, they can get somebody to fix it. 
>> They 
>> will thank us in the long run when scammers can't phish using them as a prop.

I agree too. I'm pretty sure there are more small organizations using
provider e-mail addresses than little private mail servers sending
less than 1000 messages a day, so let's declare both of those out of
scope. Or maybe not.

>I agree.  Setting p=none makes DMARC non-actionable.  I, for one, keep p=none 
>because of mailing lists.

I keep it because none of my domains are particular phish targets and
I would prefer to get my mail delivered, even the part of it that
DMARC can't describe.

R's,
John

PS: This really is off in the weeds, isn't it?

___
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

2021-01-02 Thread Alessandro Vesely


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 have names that the subscribers will recognize, but the scout 
troop only has the Yahoo address.


There are certainly kludges that one can apply to circumvent DMARC 
rejections, but this is a clear failure, an existing legitimate mail use that 
DMARC breaks.



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 breaks, they can get somebody to fix it. They 
will thank us in the long run when scammers can't phish using them as a prop.



I agree.  Setting p=none makes DMARC non-actionable.  I, for one, keep p=none 
because of mailing lists.


MLMs seem to be much better than ESPs, since their From: rewriting solves DMARC 
problems effectively, creating only an acceptable noise.


I added two new tickets:
https://trac.ietf.org/trac/dmarc/ticket/92
https://trac.ietf.org/trac/dmarc/ticket/93


Best
Ale
--















___
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

2020-12-31 Thread Michael Thomas



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 
scout troop only has the Yahoo address.


There are certainly kludges that one can apply to circumvent DMARC 
rejections, but this is a clear failure, an existing legitimate mail 
use that DMARC breaks.



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 breaks, they can get 
somebody to fix it. They will thank us in the long run when scammers 
can't phish using them as a prop.


Mike

___
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

2020-12-31 Thread John R Levine


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 are certainly kludges that one can apply to circumvent DMARC 
rejections, but this is a clear failure, an existing legitimate mail use 
that DMARC breaks.


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 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 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.



Best
Ale
--



















___
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

2020-12-31 Thread John R Levine


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, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

___
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 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 the 
question.


Discussing the split deserves its own ticket, IMHO.

Best
Ale



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, 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 minor tweaks in the first 
paragraphs of Section 3, the whole discussion about external destinations 
has to be stroked and replaced with a reference to aggregate reporting.



I removed duplicated text and adjusted references.  Diffs available here:

https://tools.ietf.org/rfcdiff?url1=draft-ietf-dmarc-failure-reporting-00=https://raw.githubusercontent.com/ietf-wg-dmarc/draft-ietf-dmarc-failure-reporting/main/draft-ietf-dmarc-failure-reporting.txt 




If the WG agrees, I'd post that as -01 and close ticket #55.


Best
Ale



Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

___
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


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 actually happened and real world effects of DMARC.


I'd guess the problem they experienced have been mailing list and submissions 
using ISP's bundled services or similar unauthorized MSAs.  The former is fixed 
by From: rewriting, the latter has no possible fix.


Not a good guess.  Please review previous messages in this thread for clues.



Ah, yeah, the ESPs.  Besides dmarc=fail, they also trigger some SA macros, such 
as FORGED_GMAIL_RCVD, FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM, 
FROM_EXCESS_BASE64, HEADER_FROM_DIFFERENT_DOMAINS, HTML_IMAGE_RATIO_04, 
HTML_MESSAGE, ...




Are there other unwanted effects?


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?


Best
Ale
--














___
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

2020-12-31 Thread John R Levine

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, 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 minor tweaks in the first 
paragraphs of Section 3, the whole discussion about external destinations 
has to be stroked and replaced with a reference to aggregate reporting.



I removed duplicated text and adjusted references.  Diffs available here:

https://tools.ietf.org/rfcdiff?url1=draft-ietf-dmarc-failure-reporting-00=https://raw.githubusercontent.com/ietf-wg-dmarc/draft-ietf-dmarc-failure-reporting/main/draft-ietf-dmarc-failure-reporting.txt


If the WG agrees, I'd post that as -01 and close ticket #55.


Best
Ale



Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly___
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 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:
https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-failure-reporting

I don't think the text is final, though.  Besides minor tweaks in the first 
paragraphs of Section 3, the whole discussion about external destinations has 
to be stroked and replaced with a reference to aggregate reporting.



I removed duplicated text and adjusted references.  Diffs available here:

https://tools.ietf.org/rfcdiff?url1=draft-ietf-dmarc-failure-reporting-00=https://raw.githubusercontent.com/ietf-wg-dmarc/draft-ietf-dmarc-failure-reporting/main/draft-ietf-dmarc-failure-reporting.txt


If the WG agrees, I'd post that as -01 and close ticket #55.


Best
Ale
--

















___
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

2020-12-31 Thread John Levine

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 DMARC.
>
>I'd guess the problem they experienced have been mailing list and submissions 
>using ISP's bundled services or similar unauthorized MSAs.  The former is 
>fixed 
>by From: rewriting, the latter has no possible fix.

Not a good guess.  Please review previous messages in this thread for clues.

>Are there other unwanted effects?

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.

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 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 and send their announcements through ESPs like
Constant Contact and Mailchimp.  This is yet another situation where
DMARC can't describe an entirely normal mail setup.

Constant Contact apparently got Yahoo to give them a signing key,
at least temporarily, but that doesn't scale.


What gmail does for gsuite is generates (or not, who knows) a key and
gives you the selector to add to your dns. I don't see why that doesn't
scale for all situations.


To point out the obvious, because they use a single address at yahoo.com
or gmail.com or hotmail.com, not a private domain. These are tiny
organizations that don't have a lot of computer expertise nor a lot of
need for it. >>
But these Girl Scout troops are going to publish a DMARC policy despite their 
lack of expertise?


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 DMARC.



I'd guess the problem they experienced have been mailing list and submissions 
using ISP's bundled services or similar unauthorized MSAs.  The former is fixed 
by From: rewriting, the latter has no possible fix.


Are there other unwanted effects?

Best
Ale
--





















___
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

2020-12-31 Thread Laura Atkins



> 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
 at webmail providers and send their announcements through ESPs like
 Constant Contact and Mailchimp.  This is yet another situation where
 DMARC can't describe an entirely normal mail setup.
 
 Constant Contact apparently got Yahoo to give them a signing key,
 at least temporarily, but that doesn't scale.
>>> 
>>> What gmail does for gsuite is generates (or not, who knows) a key and
>>> gives you the selector to add to your dns. I don't see why that doesn't
>>> scale for all situations.
>> 
>> To point out the obvious, because they use a single address at
>> yahoo.com or gmail.com or hotmail.com, not a private domain. These are
>> tiny organizations that don't have a lot of computer expertise nor a
>> lot of need for it.
> 
> But these Girl Scout troops are going to publish a DMARC policy despite their 
> lack of expertise?

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 DMARC. 

laura 

-- 
Having an Email Crisis?  We can help! 800 823-9674 

Laura Atkins
Word to the Wise
la...@wordtothewise.com
(650) 437-0741  

Email Delivery Blog: https://wordtothewise.com/blog 







___
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

2020-12-30 Thread Jim Fenton


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
Constant Contact and Mailchimp.  This is yet another situation where
DMARC can't describe an entirely normal mail setup.

Constant Contact apparently got Yahoo to give them a signing key,
at least temporarily, but that doesn't scale.


What gmail does for gsuite is generates (or not, who knows) a key and
gives you the selector to add to your dns. I don't see why that 
doesn't

scale for all situations.


To point out the obvious, because they use a single address at
yahoo.com or gmail.com or hotmail.com, not a private domain. These are
tiny organizations that don't have a lot of computer expertise nor a
lot of need for it.


But these Girl Scout troops are going to publish a DMARC policy despite 
their lack of expertise?


___
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 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
Constant Contact and Mailchimp.  This is yet another situation where
DMARC can't describe an entirely normal mail setup.

Constant Contact apparently got Yahoo to give them a signing key,
at least temporarily, but that doesn't scale.

What gmail does for gsuite is generates (or not, who knows) a key and
gives you the selector to add to your dns. I don't see why that doesn't
scale for all situations.

To point out the obvious, because they use a single address at
yahoo.com or gmail.com or hotmail.com, not a private domain. These are
tiny organizations that don't have a lot of computer expertise nor a
lot of need for it.


Um, so? The have to procure a domain too which can be technically 
challenging. If they want to use outsourced email, the outsourced email 
provider should provide the support to get their selector into their 
DNS.  If they can't bother, I don't care if their email isn't delivered.


Mike

___
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

2020-12-29 Thread John Levine

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 is yet another situation where
>> DMARC can't describe an entirely normal mail setup.
>>
>> Constant Contact apparently got Yahoo to give them a signing key,
>> at least temporarily, but that doesn't scale.
>
>What gmail does for gsuite is generates (or not, who knows) a key and 
>gives you the selector to add to your dns. I don't see why that doesn't 
>scale for all situations.

To point out the obvious, because they use a single address at
yahoo.com or gmail.com or hotmail.com, not a private domain. These are
tiny organizations that don't have a lot of computer expertise nor a
lot of need for it.

___
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

2020-12-29 Thread Douglas Foster

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 not seem to be a problem yet.

On Tue, Dec 29, 2020, 3:11 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 "authorized" you mean authorized by the originating domain, I don'
> >t have a lot of sympathy since they can delegate them a selector and
> >update their DNS. Not doing so is just lazy.
>
> 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 is yet another situation where
> DMARC can't describe an entirely normal mail setup.
>
> Constant Contact apparently got Yahoo to give them a signing key,
> at least temporarily, but that doesn't scale.
>
> R's,
> John
>
> ___
> 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




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 "authorized" you mean authorized by the originating domain, I don'
t have a lot of sympathy since they can delegate them a selector and
update their DNS. Not doing so is just lazy.

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 is yet another situation where
DMARC can't describe an entirely normal mail setup.

Constant Contact apparently got Yahoo to give them a signing key,
at least temporarily, but that doesn't scale.


What gmail does for gsuite is generates (or not, who knows) a key and 
gives you the selector to add to your dns. I don't see why that doesn't 
scale for all situations.


Mike

___
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

2020-12-29 Thread John Levine

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 originating domain, I don' 
>t have a lot of sympathy since they can delegate them a selector and 
>update their DNS. Not doing so is just lazy.

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 is yet another situation where
DMARC can't describe an entirely normal mail setup.

Constant Contact apparently got Yahoo to give them a signing key,
at least temporarily, but that doesn't scale.

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

2020-12-29 Thread Alessandro Vesely


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 authentication checks due to a
shortcoming in the authentication practices of the domain owner or some
other hiccup that occurs in transit, OR by illegitimate mail (i.e., mail
not originated by or on behalf of the domain owner, so mail intended to
fraudulently impersonate the domain), specifically the kind of mail that
DMARC is purported to be designed to stop.



That kind of analysis seems to be missing from the draft.  After some years of
experience,  we should be able to provide some, I'd hope.  If not, we'd better
bluntly drop the draft.


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 convinced it isn't.



A list of failure causes w/o further considerations may well live in an 
appendix of the main document.  If failure causes are specifically categorized 
for failure reports, this document becomes a good candidate.




It also strikes me as more of an exercise in enumeration of possibilities than
an actual analysis.

Let's see. We have:

  o Illegitimate mail
  o Message changed in transit, invalidating DKIM signature

   o Unintended DKIM breakage
   o Intentional DKIM breakage (e.g. MLM)
o DKIM signatures not evaluated or not reported
o Missing DKIM signature

  o Incorrect DKIM signing
  o Incorrect SPF setup

o "Mute" forwarding (SPF failure)
o VERP disalignment

  o Unintentional domain misalignment
  o Improper assertion of DMARC policy


We regularly get problem reports whose root cause turns out to be one of
these things.



The point is working out why one cannot understand the failure reason from 
aggregate reports.  In what cases we do need a failure report in order to 
understand what's wrong?  Maybe we need better aggregate reports?


I found one problematic report today, reported by Yahoo! (Oath) on behalf of 
aol:

  

  4.31.198.44
  1
  
none
fail
fail
  


  tana.it


  
ietf.org
pass
  

  

4.31.198.44 is mail.ietf.org.  DKIM and SPF are not aligned, hence the failure. 
 I'm surprised there are no DKIM signatures.  Now I'm going to add "DKIM 
signatures not evaluated or not reported" to the list above, as it turns out 
that Yahoo! seem to report valid signatures only.  Anyway, would I have got a 
better understanding had I received a ruf as well?


One thing a failure reports brings is the Received: (or ARC) chain.  If I 
wandered how come the IETF sends messages with my header_from, a ruf might 
help.  Is that a real case?  Forwarding for email address portability (either 
"mute" or SRS) is probably not even worth being reported, since there's nothing 
a mail admin can do about that —updating the address could be done by the 
author, had the server returned a 251/551.


Today's other reports are even more straightforward.  But then I run such a 
tiny server that I don't get an interesting assortment of cases.


Another question is *if* I were running a large server and *if* that 
problematic record had a 1 zillion, how many of the 
corresponding failure reports would I read, assuming I received any?



Best
Ale
--
















___
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 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 selector and 
update their DNS. Not doing so is just lazy.


Mike

___
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

2020-12-29 Thread John Levine

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 convinced it isn't.

Sounds like a separate WCP document.  I agree it could be nice to have something
to point to when people insist that it's my fault that their DMARC rules don't
match the way my mail system works.

>It also strikes me as more of an exercise in enumeration of possibilities than
>an actual analysis.
>
>Let's see. We have:
>
>  o Illegitimate mail
>  o Message changed in transit, invalidating DKIM signature
>  o Incorrect DKIM signing
>  o Incorrect SPF setup
>  o Unintentional domain misalignment
>  o Improper assertion of DMARC policy

Don't forget

 o Normal forwarding of SPF validated mail
 o Authorized third party senders with no access to DKIM keys

Could be an interesting document.

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

2020-12-29 Thread ned+dmarc

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 authentication practices of the domain owner or some
> other hiccup that occurs in transit, OR by illegitimate mail (i.e., mail
> not originated by or on behalf of the domain owner, so mail intended to
> fraudulently impersonate the domain), specifically the kind of mail that
> DMARC is purported to be designed to stop.

That kind of analysis seems to be missing from the draft.  After some years of
experience,  we should be able to provide some, I'd hope.  If not, we'd better
bluntly drop the draft.

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 convinced it isn't.

It also strikes me as more of an exercise in enumeration of possibilities than
an actual analysis.

Let's see. We have:

 o Illegitimate mail
 o Message changed in transit, invalidating DKIM signature
 o Incorrect DKIM signing
 o Incorrect SPF setup
 o Unintentional domain misalignment
 o Improper assertion of DMARC policy

We get regularly get problem reports whose root cause turns out to be one of
these things.

I've probably missed a bunch, and this may not be the best way to compose the
list.

Ned

___
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 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 interoperability?



Ned -- rfc6589 is a ipv6 informational doc. which rfc are you actually 
referring to?


Mike
___
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

2020-12-29 Thread ned+dmarc

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 careful assessment of what needs to be hidden
> and what does not, and that in turn drags in all of the specifics we need to
> avoid in a base document of this sort.

The failure-reporting draft references RFC6591.  The only appearance of the
term "redaction" occurs in the 2nd paragraph of Section 4.1:

Referencing an approved standards document on failure reporting formats is
perfectly reasonable and even necessary.

These reports may expose sender and recipient identifiers (e.g.,
RFC5322.From addresses), and although the [RFC6591] format used for
failed-message reporting supports redaction, failed-message reporting
is capable of exposing the entire message to the report recipient.

RFC6591 doesn't go into a very detailed description.  It references RFC6590:

For privacy reasons, report generators might need to redact portions
of a reported message, such as an identifier or address associated
with the end user whose complaint action resulted in the report.  A
discussion of relevant issues and a suggested method for doing so can
be found in [RFC6590].

RFC6590, in turn, avoids the specifics of what exactly needs to be redacted.
However, it mentions the local parts of email addresses.

If anything this is an even stronger case for not referencing RFC 6590 here -
it's unnnecessary because the reference is already in the failure reporting
format specification.

I also note that RFC 6591 was published in 2012, long before PII became such a
contentious issue. Timing can be everything.

> 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?

Maybe it's the ability to relate reports from the same source with one another
which makes them manageable.  Producers of actionable reports and consumers who
react properly can be said to interoperate, can't they?

Absent agreement on what gets redacted and how? Not even close.

RFC 6590 doesn't even pass muster as a BCP, since it describes an overall
approach to solving a range of problems and explictly does not recommend
a particular practice.

This is an informational document, nothing more and nothing less.

Ned

___
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