Re: [dmarc-ietf] Header Rewriting

[Laura Atkins]

Changed the subject line because this has nothing to do with failure reports. 

> On 5 Jan 2021, at 20:04, 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).
> 
Someone mentioned it was the article I shared a few months ago. If so it’s this 
one: 
https://www.usenix.org/system/files/conference/usenixsecurity18/sec18-hu.pdf 


Note: a single study does not make any conclusion accurate. 
> 2. A single study is unlikely to be definitive about much of anything.
> 
Absolutely true. 

Anyone relying on a single piece of evidence to prove their point is wrong. I 
am absolutely sure there is a bigger body of research out there and more data. 
In fact, I was at a conference in SF many years ago reporting a study done 
between a mailbox provider and a large sender of email. Their study showed 
quite definitively that visual indicators in email do not affect user behavior 
in any statistically meaningful way. 

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

And that’s with the Extended Validation Certificate which required extensive 
checks by the certification authority. In email anyone can ‘certify’ their mail 
with DMARC. Bad actors can trivially get a DMARC pass if they control the mail. 
If we start saying ‘bypass DMARC by rewriting the From: address’ to legitimate 
mailers then every bad actor on the planet is going to do the same thing. 

Header rewriting is a poor solution to the problem of indirect mail flows. 

>> 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 think he’s representative of one kind of enduser. He’s getting a trust 
indicator in email (DMARC fails) and doesn’t understand what that indicator 
means or implies. When I shared the relevant piece of the DMARC spec causing 
the DMARC failure he told me that was ‘all gobbledygook’ and that alignment 
wasn’t even part of DMARC. 

I think this is exactly one of the types of responses we can expect from end 
users. 

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] Header Rewriting

[Douglas Foster]

I am no fan of header rewrite, but...

If you are going to talk about "Trust Indicators", we need to define terms,
which has not been done.   Here are my definitions:
- The From header is an Identity Assertion.
- DMARC is an Identity Verification technique.
- A text message saying, "This message verified by DMARC", is a Trust
Indicator.
My definitions are consistent with the way that that one study used a trust
indicator.   Using these definitions, From rewrite has nothing to do with
Trust Indicator research.  If anyone wants to assert different definitions,
please get them on the table.

The fact that users complain about From rewrite is proof that they look at
the information.This is because it is an Identity Assertion, not a
Trust Indicator.

I accept that actual Trust Indicators have a small effect, but rounding
down  to zero seems like an overstatement.   When fighting malware, I will
take all the help that I can get, even small help.

Lots of organizations use trust indicators and lots of organizations use
DMARC for validating the From address.  Message annotation has gone up
exactly because many MUAs are making the From address visible only on
request.   Common tag lines are now of the form:  "This message is from an
external source, so be careful."   I don't see that it is our job to tell
domain owners that they are wrong,

Domain administrators are within their rights to block any incoming message
for any reason.   Users routinely work with their domain administrators to
ensure that the messages that they want get accepted and messages that they
do not want get blocked.If users and domain administrators cannot solve
their differences, the user can communicate using a different domain.  If
DMARC produces false positives that cannot be resolved by this process, we
would do well to ask why.

I see no relevance between the EV experience and DMARC.   EV is an identity
verification technique, but it lacked a policy mechanism.   As a website
user, I have no way of knowing whether a particular website MUST have an EV
certificate or not.   If such a policy mechanism existed, it would have
been automated and the site would be blocked.   DMARC has a policy
mechanism, and it has been automated, so messages are blocked.

Forwarding hides information that the email filter needs to make a correct
decision.   Header rewrite hides the problem, but does not solve it.   When
we get the automation right, predicting user behavior will not be necessary.

Doug Foster


>
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Header Rewriting

[Laura Atkins]

> On 6 Jan 2021, at 12:29, Douglas Foster  
> wrote:
> 
> I am no fan of header rewrite, but...
> 
> If you are going to talk about "Trust Indicators", we need to define terms, 
> which has not been done.   Here are my definitions:
> - The From header is an Identity Assertion.
> - DMARC is an Identity Verification technique.
> - A text message saying, "This message verified by DMARC", is a Trust 
> Indicator.
> My definitions are consistent with the way that that one study used a trust 
> indicator.   Using these definitions, From rewrite has nothing to do with 
> Trust Indicator research.  If anyone wants to assert different definitions, 
> please get them on the table.
> 
> The fact that users complain about From rewrite is proof that they look at 
> the information.This is because it is an Identity Assertion, not a Trust 
> Indicator.

The header rewriting being proposed - that is header rewriting by the ESP so 
that the messages that go through their system are rewritten to point to the 
ESP and not the author of the message - means that the identity assertion is 
disconnected from the context of a message.

Want to know what mail goes through ESPs? Bank mail, social media mail, 
marketing mail. Billions of emails a day go through ESPs that you have and have 
not heard of. 

The proposal at issue is that these ESPs be allowed to rewrite the From  
address any message they handle to point to an email address they control. This 
disconnects the identity in the 5322.from address from the actual sender of the 
message. 

Most users may know who constantcontact are or mailchimp because they advertise 
widely. Some might have heard of GoDaddy but do you know what the company name 
of the GoDaddy ESP is? I don’t off the top of my head. 

> I accept that actual Trust Indicators have a small effect, but rounding down  
> to zero seems like an overstatement.   When fighting malware, I will take all 
> the help that I can get, even small help.

And now we have a malware company that rewrites headers to point to a domain 
they own and it passes DMARC and is given a Trust Indicator. Recipients are 
used to seeing domains they don’t know or understand send trusted mail from 
their bank, or their girl scout troop, or their social media company. They have 
no reason to distrust the unfamiliar identity assertion in the from address. 

> Lots of organizations use trust indicators and lots of organizations use 
> DMARC for validating the From address.  Message annotation has gone up 
> exactly because many MUAs are making the From address visible only on 
> request.   Common tag lines are now of the form:  "This message is from an 
> external source, so be careful."   I don't see that it is our job to tell 
> domain owners that they are wrong,

This has nothing to do with header rewriting at all, which is the topic at 
hand. 

> Domain administrators are within their rights to block any incoming message 
> for any reason.   Users routinely work with their domain administrators to 
> ensure that the messages that they want get accepted and messages that they 
> do not want get blocked.If users and domain administrators cannot solve 
> their differences, the user can communicate using a different domain.  If 
> DMARC produces false positives that cannot be resolved by this process, we 
> would do well to ask why.

Header rewriting doesn’t solve false positives, it increases the chances of 
them. Header rewriting for commercial messages by ESPs means that folks 
attempting to masquerade as a legitimate company have a RFC recommended way to 
evade DMARC and pretend to be the company they’re attacking. 

This isn’t random speculation, this is what is going to happen. We've spent the 
last 20 years watching spammers and phishers do everything they can to get mail 
out. If the DMARC RFC says ‘ESPs should rewrite headers to avoid DMARC policies 
on mail going through the ESP’ then we’ve just made DMARC utterly worthless. 
We’ve also set up every company that is currently using DMARC p=reject to be 
attacked in ways they cannot tract. 

> I see no relevance between the EV experience and DMARC.   EV is an identity 
> verification technique, but it lacked a policy mechanism.   As a website 
> user, I have no way of knowing whether a particular website MUST have an EV 
> certificate or not.   If such a policy mechanism existed, it would have been 
> automated and the site would be blocked.   DMARC has a policy mechanism, and 
> it has been automated, so messages are blocked.

The whole point here is that header rewriting evades the policy mechanism of 
DMARC so that messages aren’t blocked.

> Forwarding hides information that the email filter needs to make a correct 
> decision.   Header rewrite hides the problem, but does not solve it.   When 
> we get the automation right, predicting user behavior will not be necessary.

You’re going to need to provide evidence this is the case.

laura

-- 
Having an Email Crisis?  We c

Re: [dmarc-ietf] Header Rewriting

[Dave Crocker]

On 1/6/2021 2:10 AM, Laura Atkins wrote:
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 think he’s representative of one kind of enduser. 


Each of us is, of course.  But that was not the point in my 
comment/question.


The issue is whether he/you/me are sufficiently representative of an 
'average' user, where average is drawn from a population of millions (or 
these days, possibly billions.)  Because we aren't.


If there were benefit in talking about a highly specialized (and 
extremely tiny) market segment of geek users, then fine.  But we weren't.


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

[Michael Thomas]

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] Header Rewriting

[Michael Thomas]

On 1/6/21 2:10 AM, Laura Atkins wrote:


2. A single study is unlikely to be definitive about much of anything.

Absolutely true.

Anyone relying on a single piece of evidence to prove their point is 
wrong. I am absolutely sure there is a bigger body of research out 
there and more data. In fact, I was at a conference in SF many years 
ago reporting a study done between a mailbox provider and a large 
sender of email. Their study showed quite definitively that visual 
indicators in email do not affect user behavior in any statistically 
meaningful way.


Dave made a categorical statement that the only thing that can have an 
effect on phishing is filters. I provided that study as a counterpoint 
which does not support his categorical assertion. He then tried to 
assert that something completely irrelevant to email is pertinent to 
prove his point: another one off study which is irrelevant to email. At 
the very least categorical statements in the face of little data are 
ridiculous, and should be ignored.



I think he’s representative of one kind of enduser. He’s getting a 
trust indicator in email (DMARC fails) and doesn’t understand what 
that indicator means or implies. When I shared the relevant piece of 
the DMARC spec causing the DMARC failure he told me that was ‘all 
gobbledygook’ and that alignment wasn’t even part of DMARC.


I beg your pardon. I designed and implemented SSP. If you don't know 
what this is, you are unqualified to tell me what I do or don't 
understand. Take your ad hominems elsewhere.


Mike, newbies


___
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

[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

[Michael Thomas]

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] Header Rewriting

[Michael Thomas]

On 1/6/21 4:52 AM, Laura Atkins wrote:


Most users may know who constantcontact are or mailchimp because they 
advertise widely. Some might have heard of GoDaddy but do you know 
what the company name of the GoDaddy ESP is? I don’t off the top of my 
head.


An extremely dubious assertion. Source? I barely know who they are and 
could not name them unless I saw their names first.


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

[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] Header Rewriting

[Laura Atkins]

> On 6 Jan 2021, at 15:14, Michael Thomas  wrote:
> 
> 
> On 1/6/21 4:52 AM, Laura Atkins wrote:
>> 
>> Most users may know who constantcontact are or mailchimp because they 
>> advertise widely. Some might have heard of GoDaddy but do you know what the 
>> company name of the GoDaddy ESP is? I don’t off the top of my head.
> 
> An extremely dubious assertion. Source? I barely know who they are and could 
> not name them unless I saw their names first.


That was actually my point. One you decided to clipp out of the email you’re 
replying to. Having these companies rewrite the 5322.from address to domains 
they control does not increase security. It is an end run around the small 
amount of protection DMARC offers and is a bad idea. 

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] Header Rewriting

[Michael Thomas]

On 1/6/21 7:20 AM, Laura Atkins wrote:



On 6 Jan 2021, at 15:14, Michael Thomas > wrote:



On 1/6/21 4:52 AM, Laura Atkins wrote:


Most users may know who constantcontact are or mailchimp because 
they advertise widely. Some might have heard of GoDaddy but do you 
know what the company name of the GoDaddy ESP is? I don’t off the 
top of my head.


An extremely dubious assertion. Source? I barely know who they are 
and could not name them unless I saw their names first.


That was actually my point. One you decided to clipp out of the email 
you’re replying to. Having these companies rewrite the 5322.from 
address to domains they control does not increase security. It is an 
end run around the small amount of protection DMARC offers and is a 
bad idea.


I agree about From rewriting. But your assertion here is extremely 
dubious. But mailing lists should just die, IMO.


https://rip-van-webble.blogspot.com/2020/12/are-mailing-lists-toast.html

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

[Michael Thomas]

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

[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

[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

[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

[Michael Thomas]

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

[Dave Crocker]

On 1/6/2021 10:06 AM, Michael Thomas wrote:
The AD said to stop an hour ago. So stop. 


And yet, you didn't.

I only just, finally, read his directive.  what's your excuse?

d/

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

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

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Header Rewriting

[John Levine]

In article  you write:
>The header rewriting being proposed - that is header rewriting by the ESP so 
>that the messages that
>go through their system are rewritten to point to the ESP and not the author 
>of the message - means
>that the identity assertion is disconnected from the context of a message.
>
>Want to know what mail goes through ESPs? Bank mail, social media mail, 
>marketing mail. Billions of
>emails a day go through ESPs that you have and have not heard of. 

It's even worse than that. Some ESPs are not very good at managing
their customers. Sendgrid, one of the larger ESPs, sends me a stream
of bank phishes, fake vaccine offers and (for symmetry I suppose)
antivax kookery mixed in with the legit bulk mail and some receipts
for real transactions. They do not have a good reputation and a great
deal of the mail they send goes straight to the junk folder where it
belongs.

Header rewriting is not any sort of solution to the problems that DMARC creates.

R's,
John

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Header Rewriting

[Douglas Foster]

I don't know how ESPs and From Rewrite ended up in the same sentence.  ESPs
do not need From rewrite because they can do DKIM signing.The
incentives are all against them using or allowing From rewrite.

Taking business from criminal clients does not include allowing one client
to impersonate another client or a non-client.   Such behavior would hurt
the revenue of the ESP.


On Wed, Jan 6, 2021 at 2:12 PM John Levine  wrote:

> In article  you
> write:
> >The header rewriting being proposed - that is header rewriting by the ESP
> so that the messages that
> >go through their system are rewritten to point to the ESP and not the
> author of the message - means
> >that the identity assertion is disconnected from the context of a message.
> >
> >Want to know what mail goes through ESPs? Bank mail, social media mail,
> marketing mail. Billions of
> >emails a day go through ESPs that you have and have not heard of.
>
> It's even worse than that. Some ESPs are not very good at managing
> their customers. Sendgrid, one of the larger ESPs, sends me a stream
> of bank phishes, fake vaccine offers and (for symmetry I suppose)
> antivax kookery mixed in with the legit bulk mail and some receipts
> for real transactions. They do not have a good reputation and a great
> deal of the mail they send goes straight to the junk folder where it
> belongs.
>
> Header rewriting is not any sort of solution to the problems that DMARC
> creates.
>
> 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] Header Rewriting

[Douglas Foster]

On this topic:

Forwarding hides information that the email filter needs to make a correct
decision.   Header rewrite hides the problem, but does not solve it.   When
we get the automation right, predicting user behavior will not be necessary.


You’re going to need to provide evidence this is the case.

>
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Header Rewriting

[Douglas Foster]

A previous attempt at this reply was sent prematurely.  Sorry about that.

I said:
Forwarding hides information that the email filter needs to make a correct
decision.   Header rewrite hides the problem, but does not solve it.   When
we get the automation right, predicting user behavior will not be necessary.

Laura replied:
You’re going to need to provide evidence this is the case.

Happy to explain, but I have been saying as much for some time.

My source filtering uses five parameters:   Source IP, Reverse DNS of the
Source, Helo name, SMTP address, and From Address.

Assuming that a forwarder adds no threat content, the need to evaluate the
actual source remains.But this is difficult to do:

-- Forwarding hides the three elements of server identity behind the
forwarding server.
-- SMTP rewrite hides the source domain identity, such as the ESP which
sent the message.
-- From rewrite hides the asserted author identity.

We have hidden everything.   If the forwarder could be trusted to block all
spam, this might not be a concern.   But everybody assesses spam
differently and everybody misses some of it.   As a group, forwarding
services have an incentive to minimize false positives, so the likelihood
of spam getting through is high.   Mailing lists have different incentives,
and should be able to block spam reliably.   Whether they do so or not is
outside my experience.




>
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

[dmarc-ietf] Decorum on the DMARC WG list and BCP 94

[Seth Blank]

Working Group colleagues,

Discussion on this list is increasingly out of scope and process,
unproductive, and antagonistic. This behavior undermines the chartered work
of this group and will not be tolerated. We expect and require more civil
discourse from our participants, and remind everyone that disciplining
others is the purview of the chairs.

The current phase of work of our charter (
https://datatracker.ietf.org/doc/charter-ietf-dmarc/) is to deliver a
standards track DMARC document based upon operational feedback. We are not
relitigating SPF, DKIM, DMARC, or ARC, adding new functionality, or
rehashing other IETF documents or processes.

When we kicked off DMARC bis, Alexey outlined a clear process:
https://mailarchive.ietf.org/arch/msg/dmarc/rBWzfzDa_tOhaVdxFzUBYVi46QI/

Only tickets opened by the Chairs or a document editor to the list are in
scope for working group discussion. Everything else should result in the
creation of a ticket to be discussed later, or off-list discussion. The
Chairs re-affirm that all tickets will be brought to the list.

To be clear: Before you hit “send” on an email to this list, make sure it
is on topic for an open ticket and is not likely to escalate tensions.
Otherwise, delete the message or start a private conversation that is not
on the list.

>From here on out, due to the counter-productive nature of current list
discourse, off topic or antagonistic discussions will be given a single
public warning, per BCP 94 (https://tools.ietf.org/html/bcp94), which
implies that further violations will result in a 30 day suspension for the
participant. The ADs have been consulted, and everyone should consider
themselves warned.

Finally, several members of this working group seem to be very effective at
antagonizing each other. If a thread is spiralling, and a BCP 94 warning is
given and not heeded, all active participants in the thread after the
warning has been issued will be suspended, even if it’s to tell others to
respect the warning.

Now, let’s get back to our chartered work at hand and open tickets.

Seth, Tim, and Alexey, as Chairs

-- 

*Seth Blank* | VP, Standards and New Technologies
*e:* s...@valimail.com
*p:* 415.273.8818


This email and all data transmitted with it contains confidential and/or
proprietary information intended solely for the use of individual(s)
authorized to receive it. If you are not an intended and authorized
recipient you are hereby notified of any use, disclosure, copying or
distribution of the information included in this transmission is prohibited
and may be unlawful. Please immediately notify the sender by replying to
this email and then delete it from your system.
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Decorum on the DMARC WG list and BCP 94

[Tim Wicinski]

All

If you feel a need to be heard, that is also what the chairs are here for.

thanks
tim


On Wed, Jan 6, 2021 at 7:21 PM Seth Blank  wrote:

> Working Group colleagues,
>
> Discussion on this list is increasingly out of scope and process,
> unproductive, and antagonistic. This behavior undermines the chartered work
> of this group and will not be tolerated. We expect and require more civil
> discourse from our participants, and remind everyone that disciplining
> others is the purview of the chairs.
>
> The current phase of work of our charter (
> https://datatracker.ietf.org/doc/charter-ietf-dmarc/) is to deliver a
> standards track DMARC document based upon operational feedback. We are not
> relitigating SPF, DKIM, DMARC, or ARC, adding new functionality, or
> rehashing other IETF documents or processes.
>
> When we kicked off DMARC bis, Alexey outlined a clear process:
> https://mailarchive.ietf.org/arch/msg/dmarc/rBWzfzDa_tOhaVdxFzUBYVi46QI/
>
> Only tickets opened by the Chairs or a document editor to the list are in
> scope for working group discussion. Everything else should result in the
> creation of a ticket to be discussed later, or off-list discussion. The
> Chairs re-affirm that all tickets will be brought to the list.
>
> To be clear: Before you hit “send” on an email to this list, make sure it
> is on topic for an open ticket and is not likely to escalate tensions.
> Otherwise, delete the message or start a private conversation that is not
> on the list.
>
> From here on out, due to the counter-productive nature of current list
> discourse, off topic or antagonistic discussions will be given a single
> public warning, per BCP 94 (https://tools.ietf.org/html/bcp94), which
> implies that further violations will result in a 30 day suspension for the
> participant. The ADs have been consulted, and everyone should consider
> themselves warned.
>
> Finally, several members of this working group seem to be very effective
> at antagonizing each other. If a thread is spiralling, and a BCP 94 warning
> is given and not heeded, all active participants in the thread after the
> warning has been issued will be suspended, even if it’s to tell others to
> respect the warning.
>
> Now, let’s get back to our chartered work at hand and open tickets.
>
> Seth, Tim, and Alexey, as Chairs
>
> --
>
> *Seth Blank* | VP, Standards and New Technologies
> *e:* s...@valimail.com
> *p:* 415.273.8818
>
>
> This email and all data transmitted with it contains confidential and/or
> proprietary information intended solely for the use of individual(s)
> authorized to receive it. If you are not an intended and authorized
> recipient you are hereby notified of any use, disclosure, copying or
> distribution of the information included in this transmission is prohibited
> and may be unlawful. Please immediately notify the sender by replying to
> this email and then delete it from your system.
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Decorum on the DMARC WG list and BCP 94

[Dave Crocker]

On 1/6/2021 4:21 PM, Seth Blank wrote:
and is not likely to escalate tensions. 



Seth,

Sorry, but please provide guidelines for how anyone is supposed to 
evaluate their draft posting, in that regard?


And please do it with respect to the current list rather than in 
abstract and generic terms.



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] Decorum on the DMARC WG list and BCP 94

[Michael Thomas]

On 1/6/21 4:21 PM, Seth Blank wrote:

Working Group colleagues,

Discussion on this list is increasingly out of scope and process, 
unproductive, and antagonistic. This behavior undermines the chartered 
work of this group and will not be tolerated. We expect and require 
more civil discourse from our participants, and remind everyone that 
disciplining others is the purview of the chairs.


I completely recommend everybody read and understand this paper. It 
doesn't address every answer to every question, but it does allow us to 
be much more data driven rather than uninformed conjecture. It's fine to 
dispute its conclusions, but it is not fine to dispute it to just 
dismiss it out of hand based on feelings or bias. It really gave me some 
grounding from the gut feelings which doesn't confirm much of anything. 
DKIM and DMARC need to more data and much less conjecture.


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

Mike


___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Decorum on the DMARC WG list and BCP 94

[Tim Wicinski]

Dave

You should have a pretty good idea based on these arguments over the past
few months to have a sense of how responses will be received. Take a step
back and take a second read.

This goes for all. Folks have very specific views of how they think mail
should work in regards to DMARC/DKIM/SPF/ARC/etc and instead of discounting
the discussion because the two views aren't identical, try to be a bit
open minded.

Tim



On Wed, Jan 6, 2021 at 9:14 PM Dave Crocker  wrote:

> On 1/6/2021 4:21 PM, Seth Blank wrote:
> > and is not likely to escalate tensions.
>
>
> Seth,
>
> Sorry, but please provide guidelines for how anyone is supposed to
> evaluate their draft posting, in that regard?
>
> And please do it with respect to the current list rather than in
> abstract and generic terms.
>
>
> 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] Decorum on the DMARC WG list and BCP 94

[Dave Crocker]

On 1/6/2021 8:47 PM, Tim Wicinski wrote:
You should have a pretty good idea based on these arguments over the 
past few months to have a sense of how responses will be received. 
Take a step back and take a second read.


This goes for all. Folks have very specific views of how they think 
mail should work



Tim,

This has nothing to do with differences in opinion.  It has to do with 
his persistent inability to conduct civil discourse in the face of 
disagreement.


Disagreement is fine.  Abuse is not.

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] Decorum on the DMARC WG list and BCP 94

[Tim Wicinski]

Dave

I agree.  But it seems one person's civil discourse is another person's
abuse.

Perhaps we can start from the position that nobody is attempting to insult
or abuse one another.
I don't believe anyone here consciously wants to be abusive to anyone else.
I have been accused of being an optimist.

tim


On Wed, Jan 6, 2021 at 11:52 PM Dave Crocker  wrote:

> On 1/6/2021 8:47 PM, Tim Wicinski wrote:
>
> You should have a pretty good idea based on these arguments over the past
> few months to have a sense of how responses will be received. Take a step
> back and take a second read.
>
> This goes for all. Folks have very specific views of how they think mail
> should work
>
>
> Tim,
>
> This has nothing to do with differences in opinion.  It has to do with his
> persistent inability to conduct civil discourse in the face of disagreement.
>
> Disagreement is fine.  Abuse is not.
>
> d/
>
> --
> Dave crockerdcroc...@gmail.com
> 408.329.0791
>
> Volunteer, Silicon Valley Chapter
> American Red crossdave.crock...@redcross.org
>
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc