subject:"\[dmarc\-ietf\] Call for Adoption\: DMARC Use of the RFC5322.Sender Header Field"


On 9/29/2020 3:41 PM, Hector Santos wrote:
Do you have an algorithm that replaces the current one? 


I've no idea what any of your note has to do with the DKIM protocol 
specification.


By way of a small example, DKIM does not have o=.

But really, nothing in your note concerns the published and approved 
specification.


d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field


On 9/29/2020 3:41 PM, Hector Santos wrote:
Do you have an algorithm that replaces the current one? 


I've no idea what any of your note has to do with the DKIM protocol 
specification.


By way of a small example, DKIM does not have o=.

But really, nothing in your note concerns the published and approved 
specification.


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] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

2020-09-29 Thread Hector Santos


On 9/29/2020 1:26 PM, Dave Crocker wrote:

On 9/29/2020 6:40 AM, Hector Santos wrote:

On 9/27/2020 11:44 PM, Dave Crocker wrote:
DKIM has a single signature binding requirement, the 5322.From

DMARC establishes the relationship.

I don't read it that way.

DKIM binds the signer d= domain and the from.domain with no
enforcement on it nor any indication that they are related when they
not the same (the missing link).



Absolutely not.  Please re-read the DKIM specification more carefully.
It is quite explicit that it is doing not doing this.

To the extent that you remain convinced of what you are claiming, you
need to point to the documentation that supports that view.


It began with the theory, and first implementation DomainKeys and its 
built-in policy tag "o=". Followed by DKIM early drafts with its 
enhanced signature and extended policy tag "o=" formerly known as SSP 
when separated from DKIM to create DKIM-BASE and ADSP as WG proposed 
standard work items, ADSP poisoned, returns as DMARC, since then.


Since the very beginning, my implementation, one of the better 
implementations of DKIM in the market, algorithmically and 
programmatically, follow the DKIM-BASE, DKIM-POLICY process model 
which binds, at a minimum, the RFC5322.From header, with a signer 
domain with an inherent and implicit and explicit intent and reason 
for this association.


Per the abstract, my experience suggest the question has never been 
answered, nor the association separated from the original concept.


Do you have an algorithm that replaces the current one?


--
Hector Santos,
https://secure.santronics.com
https://twitter.com/hectorsantos


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

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field


On 9/29/2020 10:46 AM, Alessandro Vesely wrote:

On Tue 29/Sep/2020 19:26:21 +0200 Dave Crocker wrote:

On 9/29/2020 6:40 AM, Hector Santos wrote:

On 9/27/2020 11:44 PM, Dave Crocker wrote:
DKIM has a single signature binding requirement, the 5322.From

DMARC establishes the relationship.

I don't read it that way.

DKIM binds the signer d= domain and the from.domain with no 
enforcement on it nor any indication that they are related when they 
not the same (the missing link). 



Absolutely not.  Please re-read the DKIM specification more 
carefully. It is quite explicit that it is doing not doing this.



I think that by "binding" Hector meant this:

5.4.  Determine the Header Fields to Sign

   The From header field MUST be signed (that is, included in the "h="
   tag of the resulting DKIM-Signature header field).
https://tools.ietf.org/html/rfc6376#section-3.4

The spec doesn't say why, but obviously holds that the From: domain is 
a specially meaningful one.  There are various other passages, for 
example:



Sigh,  yes. It has caused this misunderstanding, from the start.

It was imposed on the working group by an IETF Area Director and was 
agreed to as an expedient.


But, sigh, no. It does not carry any of the semantic import being 
claimed in the current discussion.




d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

2020-09-29 Thread Alessandro Vesely


On Tue 29/Sep/2020 19:26:21 +0200 Dave Crocker wrote:

On 9/29/2020 6:40 AM, Hector Santos wrote:

On 9/27/2020 11:44 PM, Dave Crocker wrote:
DKIM has a single signature binding requirement, the 5322.From

DMARC establishes the relationship.

I don't read it that way.

DKIM binds the signer d= domain and the from.domain with no enforcement on it 
nor any indication that they are related when they not the same (the missing 
link). 



Absolutely not.  Please re-read the DKIM specification more carefully. It is 
quite explicit that it is doing not doing this.



I think that by "binding" Hector meant this:

5.4.  Determine the Header Fields to Sign

   The From header field MUST be signed (that is, included in the "h="
   tag of the resulting DKIM-Signature header field).
   https://tools.ietf.org/html/rfc6376#section-3.4

The spec doesn't say why, but obviously holds that the From: domain is a 
specially meaningful one.  There are various other passages, for example:


   The order in which Verifiers try DKIM-Signature header fields is not
   defined; Verifiers MAY try signatures in any order they like.  For
   example, one implementation might try the signatures in textual
   order, whereas another might try signatures by identities that match
   the contents of the From header field before trying other signatures.
   https://tools.ietf.org/html/rfc6376#section-8.15

(I think this can be an answer to part [2] of ticket #38.)


Best
Ale
--






















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

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

2020-09-29 Thread Dotzero

On Tue, Sep 29, 2020 at 1:26 PM Dave Crocker  wrote:

> On 9/29/2020 6:40 AM, Hector Santos wrote:
> > On 9/27/2020 11:44 PM, Dave Crocker wrote:
> > DKIM has a single signature binding requirement, the 5322.From
> >> DMARC establishes the relationship.
> > I don't read it that way.
> >
> > DKIM binds the signer d= domain and the from.domain with no
> > enforcement on it nor any indication that they are related when they
> > not the same (the missing link).
>
>
> Absolutely not.  Please re-read the DKIM specification more carefully.
> It is quite explicit that it is doing not doing this.
>
> To the extent that you remain convinced of what you are claiming, you
> need to point to the documentation that supports that view.
>
>
> > But if they are the same domain, then they are viewed as self-signed
> > and 100% related.
>
> Not based on the DKIM specification.
>
> To the extent that you remain convinced of what you are claiming, you
> need to point to the documentation that supports that view.
>
>
> > The DKIM POLICY
>
> DKIM has no construct that qualifies as 'policy'.
>
> To the extent that you remain convinced of what you are claiming, you
> need to point to the documentation that supports that view.
>
>
> d/
>
> --
> Dave Crocker
> Brandenburg InternetWorking
> bbiw.net
>

Even though Dave and I may disagree on other things, he is 100% correct on
the above. This is one of the reasons we came up with DMARC.

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

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field


On 9/29/2020 6:40 AM, Hector Santos wrote:

On 9/27/2020 11:44 PM, Dave Crocker wrote:
DKIM has a single signature binding requirement, the 5322.From

DMARC establishes the relationship.

I don't read it that way.

DKIM binds the signer d= domain and the from.domain with no 
enforcement on it nor any indication that they are related when they 
not the same (the missing link). 



Absolutely not.  Please re-read the DKIM specification more carefully.  
It is quite explicit that it is doing not doing this.


To the extent that you remain convinced of what you are claiming, you 
need to point to the documentation that supports that view.



But if they are the same domain, then they are viewed as self-signed 
and 100% related.


Not based on the DKIM specification.

To the extent that you remain convinced of what you are claiming, you 
need to point to the documentation that supports that view.




The DKIM POLICY


DKIM has no construct that qualifies as 'policy'.

To the extent that you remain convinced of what you are claiming, you 
need to point to the documentation that supports that view.



d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

2020-09-29 Thread Hector Santos


On 9/27/2020 11:44 PM, Dave Crocker wrote:

On 9/27/2020 11:22 AM, Scott Kitterman wrote:

This seems to me to be an odd view because no RFC is needed to use From and
it's relationship to either DKIM signing domain or SPF validated Mail From.


The DKIM d= value establishes no relationship with any other
identifer, such as the From: field.  At all.  None.


DKIM has a single signature binding requirement, the 5322.From


DMARC establishes the relationship.


I don't read it that way.

DKIM binds the signer d= domain and the from.domain with no 
enforcement on it nor any indication that they are related when they 
not the same (the missing link). But if they are the same domain, then 
they are viewed as self-signed and 100% related.


But who cares? A blind receiver will not know the actual relationship 
until it sees your DMARC record, if any, and we chose that to be based 
off the 5322.From domain -- the anchor field.


The DKIM POLICY augmented (add-on) technologies published (via DNS) a 
protocol expectation for a direct or indirect relationship.  DMARC 
describes a specific rule for a direct relationship. SSP had its 
rules, DSAP had its rules, and ADSP had its rules. But all of them had 
one thing in common -- an option to publish a public policy describing 
a direct and exclusive 1 to 1 relationship and a strong action is 
authorized when there is a deviation.  That was always the power of 
all this and why we are still here 15+ years.  Without it, imo, we 
would not be here. SPF would not be here if it didn't have a -ALL 
policy with strong authorization to reject with no questions asked.



To reiterate: Among currently published specifications, without DMARC
there is no relationship between DKIM's d= value and the rfc5322.From
domain name.


To give you credit, you have been preaching this for at least a decade 
or more, always trying to establish non-binding relationship when the 
fact is, it is already burned into the DKIM protocol - the only header 
you MUST bind is 5322.From.  So how can it be said there is no strong 
relationship between the two identities embedded in the DKIM protocol? 
 You might be seeing this from a 3rd party list service where it 
doesn't wish to care what domains are using. It doesn't care.  It 
doesn't honor DMARC domains with restrictive policies.


DKIM policy protocol was always about providing the "authorizing" and 
"enforcement" protocol to act/respond to negative deviations from the 
published expectation for the published DKIM Mail policy.  If the 
publisher makes a public statement "I expect you to see XYZ"  But the 
receiver sees ABC, the DKIM Policy provides the receiver guidance as 
to what action is suggested.  In the case of  DMARC, we have:


p=reject (you can permanently reject)
p=quarantine (accept but put into spam box)
p=none (maybe you shouldn't judge based on DMARC deviations)

The problem, in my view, it is protocol incomplete. There are other 
scenarios not covered by the DMARC protocol syntax and language. We 
need an extended language for Domain Owners to communicate with DMARC 
processors in dealing with the deviation is a 3rd party signer domain.


So I need to see how using Sender fits into the equation. What can the 
DMARC domain owner "describe" via the 5322.From policy statement that 
says


"Please look at the Sender address using Dave's protocol steps before 
looking at the Author address"


Example, maybe using a tag.

DMARC p=reject sender=1

This offers backward compatibility. This could tell the receiver to 
consider using Dave's Sender protocol for DMARC before falling back to 
DMARC original logic. Don't try to ram Sender down DmarcBis's throat 
without some extended switch. If you want to explore an extension, a 
tag such as sender=1 could be used to trigger the a newer exploratory 
logic.


BTW, what are those steps? can it be outlined in itemized steps?

--
Hector Santos,
https://secure.santronics.com
https://twitter.com/hectorsantos


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

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

2020-09-28 Thread Dave Crocker


On 9/28/2020 5:32 PM, Scott Kitterman wrote:

but
pretending like DMARC policy doesn't exist is not.


Claims of pretending seem to be popular just now.  the problem seems to 
be adequately explaing  the pretending.


So to contribute the response portion of this ritual:

   1. No one is pretending anything.

   2. Since you believe otherwise, please document it.

d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

2020-09-28 Thread Scott Kitterman

On Monday, September 28, 2020 11:35:58 AM EDT Kurt Andersen (b) wrote:
> On Sun, Sep 27, 2020 at 11:23 AM Scott Kitterman 
> 
> wrote:
> > On Sunday, September 27, 2020 1:16:11 PM EDT John Levine wrote:
> > 
> > Agreed.  Maybe it would help if someone who takes the latter view would
> > 
> > explain what they think RFC 7489, Section 6.6.2, Step 6 is for:
> > >6.  Apply policy.  Emails that fail the DMARC mechanism check are
> > >
> > >disposed of in accordance with the discovered DMARC policy of the
> > >Domain Owner.  See Section 6.3 for details.
> > 
> > I don't think that says "then toss the results into your classifier".
> 
> You completely ignored section 6.7 (Policy Enforcement Considerations)
> 
> which states:
> > Final disposition of a message is always a matter of local policy.
> 
> Local policy could be considered "the output of some classifier" or other
> mechanics left to the invention of the receiver.
> 
> This is a part of the documented DMARC spec, not a change.

Yes and that would be equally true even if RFC 7489 were silent on the matter.  
Receiver always gets to decide and there's no way DMARC could pretend to 
mandate delivery and not get laughed out of the room.

It's part of the documented specification, but so is 6.6.2(6).  I think that's 
there to make it clear there's no attempt at a delivery mandate.  There's no 
interoperability or protocol associated with it.  My view is that using local 
policy to override the 6.6.2(d) domain owner policy for disposition of 
messages that do not pass DMARC checks is in the spirit of the thing, but 
pretending like DMARC policy doesn't exist is not.

Scott K

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

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

2020-09-28 Thread Kurt Andersen (b)

On Mon, Sep 28, 2020 at 10:46 AM Dave Crocker  wrote:

> . . .given that 'disposing of' the message is a domain owner goal,
> frequently, perhaps changing "disposed of" to "processed" would be less
> inviting of misunderstanding?
>

Yes, I think that, at least in American English usage, "disposal" tends to
have a bit of a pejorative connotation.  Consider that in the context of
people who have to deal with truckloads of UCE and other bulk email and the
negative association becomes even stronger.

+1 to adjusting the terminology to be less biased.

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

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

2020-09-28 Thread Dave Crocker

On 9/28/2020 8:35 AM, Kurt Andersen (b) wrote:

>   6.  Apply policy.  Emails that fail the DMARC mechanism check are
>        disposed of in accordance with the discovered DMARC
policy of the
>        Domain Owner.  See Section 6.3 for details.

I don't think that says "then toss the results into your classifier".

You completely ignored section 6.7 (Policy Enforcement Considerations) 
which states:

> Final disposition of a message is always a matter of local policy.

Local policy could be considered "the output of some classifier" or 
other mechanics left to the invention of the receiver.

This is a part of the documented DMARC spec, not a change.

drat.  yes.

I was far too distracted by the word 'disposed of'.  given that it is 
related to 'disposition' there's nothing semantically wrong with its use.

but given that 'disposing of' the message is a domain owner goal, 
frequently, perhaps changing "disposed of" to "processed" would be less 
inviting of misunderstanding? robustness against reasonable 
misunderstanding is helpful... (I could even squeeze in a reference to 
the Postel rule, applied to specification writing.)

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] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

2020-09-28 Thread Kurt Andersen (b)

On Sun, Sep 27, 2020 at 11:23 AM Scott Kitterman 
wrote:

> On Sunday, September 27, 2020 1:16:11 PM EDT John Levine wrote:
>
> Agreed.  Maybe it would help if someone who takes the latter view would
> explain what they think RFC 7489, Section 6.6.2, Step 6 is for:
>
> >6.  Apply policy.  Emails that fail the DMARC mechanism check are
> >disposed of in accordance with the discovered DMARC policy of the
> >Domain Owner.  See Section 6.3 for details.
>
> I don't think that says "then toss the results into your classifier".
>

You completely ignored section 6.7 (Policy Enforcement Considerations)
which states:

> Final disposition of a message is always a matter of local policy.

Local policy could be considered "the output of some classifier" or other
mechanics left to the invention of the receiver.

This is a part of the documented DMARC spec, not a change.

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

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

2020-09-28 Thread Scott Kitterman

On Sunday, September 27, 2020 11:44:11 PM EDT Dave Crocker wrote:
> On 9/27/2020 11:22 AM, Scott Kitterman wrote:
> > This seems to me to be an odd view because no RFC is needed to use From
> > and
> > it's relationship to either DKIM signing domain or SPF validated Mail
> > From.
> 
> The DKIM d= value establishes no relationship with any other identifer,
> such as the From: field.  At all.  None.
> 
> DMARC establishes the relationship. DMARC does other things, but for the
> above suggested alternative, this is the functional difference that
> requires DMARC.
> 
> To reiterate: Among currently published specifications, without DMARC
> there is no relationship between DKIM's d= value and the rfc5322.From
> domain name.

I just realized I neglected to respond to this part of your mail.

Right, but my mail server, my rules.  I don't need the IETF's permission to 
make such an association if I find it's a useful token for my analysis.  The 
only thing that requires any kind of formal connection is the connection to 
policy.

If you argue yourself out of the connection to policy, you've argued yourself 
out of DMARC entirely.  In order to generate the data for my classifier, it's 
entirely unnecessary to even look up the DMARC record (it might be useful as 
additional data for a more nuanced analysis, but it not needed to determine 
the relationship between rfc5322.From and DKIM d= or rfc5321.MailFrom).

Scott K

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

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

2020-09-28 Thread Scott Kitterman

On Sunday, September 27, 2020 11:58:40 PM EDT Dave Crocker wrote:
> On 9/27/2020 8:53 PM, Scott Kitterman wrote:
> > So we agree that you claim DMARC practice is in variance with what is
> > specified and we should base the update to the specification on the usage
> > you have claimed is popular?
> 
> Depends on the analysis of that behavior, but it's silly to ignore the
> behavior and pretend Step 6 is what will (always) be done.
> 
> Protocol specification revision efforts pay attention to established
> practice.

I haven't said anything about what we should do going forward.  I'm trying to 
establish where we are.

I never suggested it will always be done, so let's leave the straw men aside.

To clarify:

It's your suggestion that the established practice is not aligned to the 
current specification.  Specifically you believe that the policy action in step 
6 is used only rarely.

Is that correct?

Scott K

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

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

2020-09-28 Thread Alessandro Vesely


On Sun 27/Sep/2020 15:06:24 +0200 Dave Crocker wrote:

On 9/27/2020 2:20 AM, Alessandro Vesely wrote:

On Sat 26/Sep/2020 15:06:54 +0200 Dave Crocker wrote:

On 9/26/2020 3:31 AM, Alessandro Vesely wrote:

A pointer to a better aimed report circulated on this list:


An unrefereed presentation (not paper) about a single experiment is better 
than a summary of an industry-wide effort that failed?



I meant aimed at email rather than web browsing.


So?

If you think the industry-wide experiment that focused on signalling a trust 
indicator and failed is less relevant than a small, single, unrefereed paper 
about a preliminary and poorly-design research project is somehow less 
relevant, please explain.



I think an industry-wide experiment on petrol consumption has nothing to do 
with email protocols, however refereed.  Web browsing has a minor share with 
email, as some people use browsers instead of MUAs.  Browser security concerns 
are rather oriented toward shopping and EV certificates, than email phishing.



And, for the current discussion, there's the troublesome summary the they 
give about their own study:



1. Warning only slightly lowers the click rate
2. The absolute click rate is still high


The key words there are "slightly" and "still high".



"If one person eats a chicken and another person doesn't eat anything, on 
average they both ate half a chicken".  That's how statistics distorts reality. 


The fact that you think this statement is somehow meaningful suggests a 
rejection of an entire, established field of study based on not understanding it.



Statistics can easily be misused.  Distinguishing a cluster of overweight 
people from starving communities doesn't reject statistics as a whole.



I'm sure there are users who watch authentication results, and usually take 
no bait.  For them,  "slightly" and "still high" don't hold.


Except that individual cases are not the basis for establishing industry-wide 
practice.  Industry-wide behaviors are.


An occasional example simply isn't relevant.  That's the difference that 
legitimate statistical analysis provides.



The statistical aspect of email is that it is mostly spam, at varying shades of 
gray.  Meaningful messages can be regarded as occasional exceptions in this 
respect.  Nevertheless, they are important.



And, there's increasing activity about anti-phish employee training.  As a 
consequence, the importance of visual hints is bound to increase.


Excellent.  So that means you can point to studies that show how effective such 
training is.  Because the general sense is in the anti-abuse community is that 
it has little effect.  But if you know of studies to the contrary, it would 
very useful to hear about them.



Google Scholar shows me 83 results about anti-phish training effectiveness. 
Just talking about human-oriented solutions for phishing entails that users 
need to interpret visual cues.  Hence visual cues have some effect, however little.


Discarding the importance of of users judgement provides for a skewed vision.

Filtering out obvious spam can be considered a favor to users, to keep their 
mailboxes cleaner.  Yet, a deterministic protocol which determines what to 
reject and what to quarantine would relieve MX operators from the 
responsibility of arbitrary filtering based on obscure secrets.




Prompting the question of why anyone would think this study serves as
demonstrating strong support for the role of end-users in abuse protection?


That wasn't the goal of the presentation, AFAIUI.


However it /was/ the apparent reason it was cited.



Yup.


All of which demonstrates a basic problem with efforts to discuss 
human-related work: difficulties in understanding how to evaluate research 
and research patterns, with a tendency to instead lean on confirmation bias.



That's why it is important to enable each and every soul to exert their own 
judgements.


Actually, it's not.



Why have elections at all if the result can be forecast before the votes are 
counted?



Best
Ale
--





















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

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field


On 9/27/2020 8:53 PM, Scott Kitterman wrote:

So we agree that you claim DMARC practice is in variance with what is specified
and we should base the update to the specification on the usage you have
claimed is popular?


Depends on the analysis of that behavior, but it's silly to ignore the 
behavior and pretend Step 6 is what will (always) be done.


Protocol specification revision efforts pay attention to established 
practice.


d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

2020-09-27 Thread Scott Kitterman

On Sunday, September 27, 2020 11:44:11 PM EDT Dave Crocker wrote:
> On 9/27/2020 11:22 AM, Scott Kitterman wrote:
> > This seems to me to be an odd view because no RFC is needed to use From
> > and
> > it's relationship to either DKIM signing domain or SPF validated Mail
> > From.
> 
> The DKIM d= value establishes no relationship with any other identifer,
> such as the From: field.  At all.  None.
> 
> DMARC establishes the relationship. DMARC does other things, but for the
> above suggested alternative, this is the functional difference that
> requires DMARC.
> 
> To reiterate: Among currently published specifications, without DMARC
> there is no relationship between DKIM's d= value and the rfc5322.From
> domain name.
> 
> > Feeding data into an algorithm has no interoperability requirements.
> > 
> > That doesn't mean one can't use the data this way, because anyone can that
> > wants to can.  That doesn't make it the specified protocol.
> 
> It's not clear what your point is.  It's clear you believe it's a
> fundamental point, but I'm not understanding it's import.
> 
> > ...  Maybe it would help if someone who takes the latter view would
> > 
> > explain what they think RFC 7489, Section 6.6.2, Step 6 is for:
> >> 6.  Apply policy.  Emails that fail the DMARC mechanism check are
> >> 
> >> disposed of in accordance with the discovered DMARC policy of the
> >> Domain Owner.  See Section 6.3 for details.
> > 
> > I don't think that says "then toss the results into your classifier".
> 
> The issue is not what it says -- though it worth considering whether
> that's what it /should/ say.
> 
> The issue is how receivers actually /use/ DMARC.
> 
> There has always be a tension about how to write these statements
> seeking to affect receiver behavior.  The natural tendency is to write
> language of simple directives, such as Step 6 -- after all, that's
> common language for basic protocol behavior.
> 
> However Step 6 moves from protocol into policy.  It is based on the myth
> that receivers will blindly follow the instructions that are provided by
> sites with which the receiver has no relationship, never mind a
> contractual one.
> 
> The reality is that Step 6 results in a mandate that often produces
> unacceptable results.
> 
> Receivers, having their own quality assurance models, immediately
> adapted their actions to their own operating criteria, rather than
> following the simple, blind directives of  random DMARC publishers.

So we agree that you claim DMARC practice is in variance with what is specified 
and we should base the update to the specification on the usage you have 
claimed is popular?

Scott K


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

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field


On 9/27/2020 11:22 AM, Scott Kitterman wrote:

This seems to me to be an odd view because no RFC is needed to use From and
it's relationship to either DKIM signing domain or SPF validated Mail From.


The DKIM d= value establishes no relationship with any other identifer, 
such as the From: field.  At all.  None.


DMARC establishes the relationship. DMARC does other things, but for the 
above suggested alternative, this is the functional difference that 
requires DMARC.


To reiterate: Among currently published specifications, without DMARC 
there is no relationship between DKIM's d= value and the rfc5322.From 
domain name.




Feeding data into an algorithm has no interoperability requirements.

That doesn't mean one can't use the data this way, because anyone can that
wants to can.  That doesn't make it the specified protocol.


It's not clear what your point is.  It's clear you believe it's a 
fundamental point, but I'm not understanding it's import.




...  Maybe it would help if someone who takes the latter view would
explain what they think RFC 7489, Section 6.6.2, Step 6 is for:


6.  Apply policy.  Emails that fail the DMARC mechanism check are
disposed of in accordance with the discovered DMARC policy of the
Domain Owner.  See Section 6.3 for details.

I don't think that says "then toss the results into your classifier".


The issue is not what it says -- though it worth considering whether 
that's what it /should/ say.


The issue is how receivers actually /use/ DMARC.

There has always be a tension about how to write these statements 
seeking to affect receiver behavior.  The natural tendency is to write 
language of simple directives, such as Step 6 -- after all, that's 
common language for basic protocol behavior.


However Step 6 moves from protocol into policy.  It is based on the myth 
that receivers will blindly follow the instructions that are provided by 
sites with which the receiver has no relationship, never mind a 
contractual one.


The reality is that Step 6 results in a mandate that often produces 
unacceptable results.


Receivers, having their own quality assurance models, immediately 
adapted their actions to their own operating criteria, rather than 
following the simple, blind directives of  random DMARC publishers.



d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

2020-09-27 Thread Scott Kitterman

On Sunday, September 27, 2020 1:16:11 PM EDT John Levine wrote:
> In article <4004580.HQKp4RnRq6@zini-1880> you write:
> >I don't think this his helpful.  If something like this is going to be
> >standardized, it shouldn't be called DMARC because it's not.
> 
> We (the generic we) seem to have a fundamendal disconnect about what
> DMARC is for.
> 
> One group appears to believe it's about what users see in their inbox,
> to ensure that the address on the From: line matches the actual
> author.

Speaking at least for myself, not quite.  I think it's more about what users 
don't see than what they see.  I think most everyone agrees DMARC is to 
support filtering, I think the question is about how.

DMARC defines a policy set with the goal that receivers will act on that 
policy.  Specifically that receivers will reject/quarantine mail that fails 
DMARC for domains that have published such restrictive policies.

The approach defined is mechanical, not statistical.  I think that's the key 
difference.  Is it about specific policy enforcement, or is it just one more 
token for a bayesian network?

> The other group appears to believe it's a filtering signal that mail
> systems mix into the filtering process they apply between the time the
> mail arrives at the MX and the time the users sees it.

This seems to me to be an odd view because no RFC is needed to use From and 
it's relationship to either DKIM signing domain or SPF validated Mail From.  
Feeding data into an algorithm has no interoperability requirements.

That doesn't mean one can't use the data this way, because anyone can that 
wants to can.  That doesn't make it the specified protocol.

> I suppose both are right to some extent, but they have very different
> implications for the design.

Agreed.  Maybe it would help if someone who takes the latter view would 
explain what they think RFC 7489, Section 6.6.2, Step 6 is for:

>6.  Apply policy.  Emails that fail the DMARC mechanism check are
>disposed of in accordance with the discovered DMARC policy of the
>Domain Owner.  See Section 6.3 for details.

I don't think that says "then toss the results into your classifier".

Scott K

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

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

2020-09-27 Thread Douglas E. Foster

I'm confused.

I thought we all agreed that From represents the author who is responsible for 
the content, and consequently it had importance to both the filtering process 
and the user.   I thought the issue at hand was that DMARC-induced header 
munging made the From address into something different then the address which 
best represents the author.   So it seemed like we had a lot to agree on.

Also, I thought a trust indicator was a statement like
"The From Address is DMARC-verified",
rather than
"This message is from user@domain"

Which leads me to several questions
- Does the research support the idea that the From address is a trust indicator?
- Is so, does it show that the only purpose of the From address is as a trust 
indicator?
- If "From" has purposes other than as a trust indicator, does it matter 
whether the value is correct or not?
- If it is true that the From address serves no purpose to the user, then is 
header munging really a problem?

DF

From: Dave Crocker 
Sent: 9/27/20 1:26 PM
To: dmarc@ietf.org
Subject: Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender 
Header Field

On 9/27/2020 10:16 AM, John Levine wrote:
> I suppose both are right to some extent, but they have very different
> implications for the design.

Except they aren't both right.

We know that it is used by filtering engines.

There is no evidence it is used by end-users. And there is a pretty long
history indicating such information is NOT used by end users.

d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

___
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] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field


On 9/27/2020 10:16 AM, John Levine wrote:

I suppose both are right to some extent, but they have very different
implications for the design.



Except they aren't both right.

We know that it is used by filtering engines.

There is no evidence it is used by end-users. And there is a pretty long 
history indicating such information is NOT used by end users.


d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

2020-09-27 Thread John Levine

In article <4004580.HQKp4RnRq6@zini-1880> you write:
>I don't think this his helpful.  If something like this is going to be 
>standardized, it shouldn't be called DMARC because it's not.

We (the generic we) seem to have a fundamendal disconnect about what
DMARC is for.

One group appears to believe it's about what users see in their inbox,
to ensure that the address on the From: line matches the actual
author.

The other group appears to believe it's a filtering signal that mail
systems mix into the filtering process they apply between the time the
mail arrives at the MX and the time the users sees it.

I suppose both are right to some extent, but they have very different
implications for the design.

R's,
John

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

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field


On 9/27/2020 2:20 AM, Alessandro Vesely wrote:

On Sat 26/Sep/2020 15:06:54 +0200 Dave Crocker wrote:

On 9/26/2020 3:31 AM, Alessandro Vesely wrote:

A pointer to a better aimed report circulated on this list:


An unrefereed presentation (not paper) about a single experiment is 
better than a summary of an industry-wide effort that failed?



I meant aimed at email rather than web browsing.


So?

If you think the industry-wide experiment that focused on signalling a 
trust indicator and failed is less relevant than a small, single, 
unrefereed paper about a preliminary and poorly-design research project 
is somehow less relevant, please explain.



And, for the current discussion, there's the troublesome summary the 
they give about their own study:



1. Warning only slightly lowers the click rate
2. The absolute click rate is still high


The key words there are "slightly" and "still high".



"If one person eats a chicken and another person doesn't eat anything, 
on average they both ate half a chicken".  That's how statistics 
distorts reality. 


The fact that you think this statement is somehow meaningful suggests a 
rejection of an entire, established field of study based on not 
understanding it.



I'm sure there are users who watch authentication 
results, and usually take no bait.  For them,  "slightly" and "still 
high" don't hold.


Except that individual cases are not the basis for establishing 
industry-wide practice.  Industry-wide behaviors are.


An occasional example simply isn't relevant.  That's the difference that 
legitimate statistical analysis provides.





And, there's increasing activity about anti-phish employee training.  As 
a consequence, the importance of visual hints is bound to increase.


Excellent.  So that means you can point to studies that show how 
effective such training is.  Because the general sense is in the 
anti-abuse community is that it has little effect.  But if you know of 
studies to the contrary, it would very useful to hear about them.





Prompting the question of why anyone would think this study serves as
demonstrating strong support for the role of end-users in abuse 
protection?


That wasn't the goal of the presentation, AFAIUI.


However it /was/ the apparent reason it was cited.




At any rate, I don't think that demeaning users can be a long term 
strategy toward a more evolved society.  Albeit it may work 99% of 
times, delegating decisions to a security manager is a limitation.  It 
is possible, at least in theory, that a message is considered a phish by 
some but not by others.  In illiberal countries that's all the more likely.



All of which demonstrates a basic problem with efforts to discuss 
human-related work: difficulties in understanding how to evaluate 
research and research patterns, with a tendency to instead lean on 
confirmation bias.



That's why it is important to enable each and every soul to exert their 
own judgements.


Actually, it's not.

d/


--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

2020-09-27 Thread Alessandro Vesely


On Sat 26/Sep/2020 15:06:54 +0200 Dave Crocker wrote:

On 9/26/2020 3:31 AM, Alessandro Vesely wrote:

A pointer to a better aimed report circulated on this list:


An unrefereed presentation (not paper) about a single experiment is better than 
a summary of an industry-wide effort that failed?



I meant aimed at email rather than web browsing.


And, for the current discussion, there's the troublesome summary the they give 
about their own study:



1. Warning only slightly lowers the click rate
2. The absolute click rate is still high


The key words there are "slightly" and "still high".



"If one person eats a chicken and another person doesn't eat anything, on 
average they both ate half a chicken".  That's how statistics distorts reality. 
 I'm sure there are users who watch authentication results, and usually take 
no bait.  For them,  "slightly" and "still high" don't hold.


And, there's increasing activity about anti-phish employee training.  As a 
consequence, the importance of visual hints is bound to increase.




Prompting the question of why anyone would think this study serves as
demonstrating strong support for the role of end-users in abuse protection?


That wasn't the goal of the presentation, AFAIUI.

At any rate, I don't think that demeaning users can be a long term strategy 
toward a more evolved society.  Albeit it may work 99% of times, delegating 
decisions to a security manager is a limitation.  It is possible, at least in 
theory, that a message is considered a phish by some but not by others.  In 
illiberal countries that's all the more likely.



All of which demonstrates a basic problem with efforts to discuss human-related 
work: difficulties in understanding how to evaluate research and research 
patterns, with a tendency to instead lean on confirmation bias.



That's why it is important to enable each and every soul to exert their own 
judgements.



Best
Ale
--

































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

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

2020-09-26 Thread Hector Santos


On 9/26/2020 7:23 PM, Seth Blank wrote:


The goal of DMARCbis is to take the independent stream informational
RFC 7489 and drive it to an IETF stream standards track document that
represents IETF consensus. So this work is explicitly around DMARC as
a protocol that describes how a domain owner transmits its policy for
mail that does not authenticate to a mail receiver.

Further, our charter takes the usefulness of DMARC in its current form
as table stakes, and (to paraphrase) primarily focuses our discussion
around addressing limitations or operational concerns of the protocol.

One of the primary limitations of DMARC is when mail transits through
a forwarder that breaks authentication. For DMARC to go standards
track, this issue must be addressed. Currently ARC is the approved
experiment from Phase 2 of our Charter.

Seth, as Chair


Thanks for the summary. Are any of authorized third party proposals on 
the table?



--
Hector Santos,
https://secure.santronics.com
https://twitter.com/hectorsantos


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

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

2020-09-26 Thread Seth Blank

On Sat, Sep 26, 2020 at 3:50 PM Scott Kitterman 
wrote:

> Is the context in terms of the protocol specified by RFC 7489?
>

Yes.

> That may sound like a silly question, but I think fundamentally if "DMARC"
> is
> just an input to a filter or if "DMARC" is a protocol to reject/quarantine
> email that meets certain policy criteria makes a big difference in how
> some of
> these questions are addressed.
>

The goal of DMARCbis is to take the independent stream informational RFC
7489 and drive it to an IETF stream standards track document that
represents IETF consensus. So this work is explicitly around DMARC as a
protocol that describes how a domain owner transmits its policy for mail
that does not authenticate to a mail receiver.

Further, our charter takes the usefulness of DMARC in its current form as
table stakes, and (to paraphrase) primarily focuses our discussion around
addressing limitations or operational concerns of the protocol.

One of the primary limitations of DMARC is when mail transits through a
forwarder that breaks authentication. For DMARC to go standards track, this
issue must be addressed. Currently ARC is the approved experiment from
Phase 2 of our Charter.

Seth, as Chair
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

2020-09-26 Thread Scott Kitterman

On Saturday, September 26, 2020 3:56:44 PM EDT Seth Blank wrote:
> Thank you, everyone, for backing off the personal attacks and apologizing.
> 
> Now let's get back to the technical merits of the open tickets, please--
> we'd like to close the current 3 out and open the next batch early next
> week.

Is the context in terms of the protocol specified by RFC 7489?

That may sound like a silly question, but I think fundamentally if "DMARC" is 
just an input to a filter or if "DMARC" is a protocol to reject/quarantine 
email that meets certain policy criteria makes a big difference in how some of 
these questions are addressed.

If I'm going to dive into details, I want to first make sure I understand the 
context.

Scott K

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

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

2020-09-26 Thread ned+dmarc


...



Well, ok, here's one that shows lack of efficacy, and it's a big one: 
EV-certs



/Google to bury indicator for Extended Validation certs in Chrome
because users barely took notice/



https://www.theregister.com/2019/08/12/google_chrome_extended_validation_certificates/



"The reason is simple. "Through our own research as well as a survey of
prior academic work, the Chrome Security UX team has determined that the
EV UI does not protect users as intended... users do not appear to make
secure choice..."


To be fair, this is looking at positive security indicators, not negative
ones. But there are plenty of other studies looking at the more general
case. Here's one that seems relevant to DMARC:

  Do Security Toolbars Actually Prevent Phishing Attacks?
  https://dl.acm.org/doi/pdf/10.1145/1124772.1124863

  Abstract:

  Security toolbars in a web browser show security-related
  information about a website to help users detect phishing
  attacks. Because the toolbars are designed for humans to
  use, they should be evaluated for usability - that is, whether
  these toolbars really prevent users from being tricked into
  providing personal information. We conducted two user
  studies of three security toolbars and other browser security
  indicators and found them all ineffective at preventing
  phishing attacks. Even though subjects were asked to pay
  attention to the toolbar, many failed to look at it; others
  disregarded or explained away the toolbars' warnings if the
  content of web pages looked legitimate. We found that
  many subjects do not understand phishing attacks or realize
  how sophisticated such attacks can be. 


Ned

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

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field


On 9/26/2020 8:41 AM, Scott Kitterman wrote:

On Friday, September 25, 2020 11:03:51 PM EDT Dave Crocker wrote:

Perhaps you have not noticed but the demonstrated field use of DMARC, to
date, tends to be contrary to the design, to the extent anyone thinks
that the design carries a mandate that receivers follow the directives
of the domain owners.

So the text in the draft merely reflects real-world operational style.

I think it's not nearly as clear as you seem to think.  If the standard is
users will not 100% do the right thing, then I agree that won't happen, but I
don't think it's a reasonable standard.  I think the standard ought to be that
there is an overall tendency towards reduced risk.


And there is no (or perhaps only minuscule) evidence that such a 
tendency is demonstrated.


Even the 'study' you cited uses the word 'slight'.

The larger question is:  where is the body of research and/or experience 
that demonstrates the positive effect you are relying on?  As far as I 
know "trust indicators" have somewhere between a poor and a terrible 
history.  So to the extent you believe they are helpful, please produce 
the body of work demonstrating it.


My real point is that we /know/ there is a critical and demonstrably 
useful -- actually, essential -- function performed by anti-abuse 
filtering engines at receivers, independent of the end-user.  Good ones 
reduce incoming abuse down from roughly 95% of the stream to a tiny 
percent.


DMARC processing is included in some such engines' repertoire.

The proposal adds to that, but based on the Sender: field, rather than 
the From: field.




My claim is that this proposal is substantially at odds with the protocol as
documented (#1).


I disagree.

Again, please clarify exactly how it is at odds and please explain in 
detail what real-world processing of DMARC it impedes.




I think we agree that this proposal is at odds with DMARC as documented.


We do not agree.

Again, rather than making a broad claim, please provide actual detail to 
substantiate your claim.



d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

2020-09-26 Thread Seth Blank

Thank you, everyone, for backing off the personal attacks and apologizing.

Now let's get back to the technical merits of the open tickets, please--
we'd like to close the current 3 out and open the next batch early next
week.


On Sat, Sep 26, 2020 at 12:08 PM Douglas E. Foster  wrote:

> My apology, Dave, for letting my frustration get the best of me.
>
>
>
> Doug Foster
>
>
>
>
> --
> *From*: Tim Wicinski 
> *Sent*: 9/26/20 12:33 PM
> *To*: fost...@bayviewphysicians.com
> *Cc*: "dmarc@ietf.org" 
> *Subject*: Re: [dmarc-ietf] Call for Adoption: DMARC Use of the
> RFC5322.Sender Header Field
>
>
> And here we were getting along so well!
>
> Mr Foster, it's perfectly fine to disagree with Mr Crocker technical
> points, and you are
> welcome to have your own opinion on whether he chooses to hear or not.
> But those opinions should
> be kept to yourself.
>
> I see a lot of these heated discussions as a sign that people really care
> about this issue. That's
> a good thing.
>
> For the record, I'm a DNS person.  I see most problems as being solved
> with more DNS, or less DNS.
> I will say that I have had "passionate discussions" with Mr Crocker on
> several issues and I found that
> it was not that he did not listen, but figuring out how to better explain
> my point of view.
> Surprisingly to many, he does listen.
>
> Whether this work is in scope for DMARC or not, I would plead guilty for
> not considering this carefully.
> In the DNSOP working group I co-chair, *everything* DNS is in scope, until
> it is not in scope.
> These types of discussions I was leaning on Seth, Alexey and of course
> Murray the AD.
>
> thanks for listening.
> tim
>
>
> On Sat, Sep 26, 2020 at 8:55 AM Douglas E. Foster  40bayviewphysicians@dmarc.ietf.org> wrote:
>
>> The problems with your proposal have been well documented, but you
>> apparently choose not to hear.   The single paragraph that Scott quoted has
>> multiple problems within it.
>>
>> The group has considered other and better technical proposals
>> (conditional signatures, ATSP, RHSWL), but they have all been dropped
>> because the group did not believe that Domain Owners would have any desire
>> to implement them, and because Mailing List Operators would have no way of
>> knowing which mailing lists had implemented the new feature.
>>
>> If you have solutions to these problems, please put them forward.
>> Otherwise, why are we dragging this back up?
>>
>>
>> --
>> *From*: Dave Crocker 
>> *Sent*: 9/25/20 11:04 PM
>> *To*: Scott Kitterman 
>> *Cc*: IETF DMARC WG 
>> *Subject*: Re: [dmarc-ietf] Call for Adoption: DMARC Use of the
>> RFC5322.Sender Header Field
>>
>> On 9/25/2020 4:21 PM, Scott Kitterman wrote:
>>
>> On Friday, September 25, 2020 7:05:22 PM EDT Dave Crocker wrote:
>>
>> I think the obligation to justify is on the advocate for change.
>>
>> That means you are demanding I prove  negative.  Which, of course, is an
>> impossible assignment.
>>
>> Rather, the obligation is on the person claiming the affirmative, which
>> in this case means the claim that this proposal somehow 'breaks' or
>> otherwise hurts DMARC.
>>
>>
>> Because the current email protection behavior involves the
>>RFC5322.From field, and pertain to the human author, it is common to
>>think that the issue, in protecting the field's content, is behavior
>>of the human recipient.  However there is no indication that the
>>enforced values in the RFC5322.From field alter end-user behavior.
>>In fact there is a long train of indication that it does not.
>>   Rather, the meaningful protections actually operate at the level of
>>the receiving system's mail filtering engine, which decides on the
>>dispostion of received mail.
>>
>> Please provide references for your long train of indications, speaking of
>> making overly broad assumptions.  If that's accurate, I'd like to understand
>> the data that tells us that.
>>
>> I'm not going to do that, because there's a long history of that work
>> being ignored, in spite of it being reviewed repeatedly in thse and related
>> fora over the years.  It's gotten tiresome to have people claiming an
>> effect that they lacks evidence for, and the data to the contrary that they
>> are somehow unaware of.
>>
>> Again, the real requirement is focus on the affirmative.
>>
>> In this case, an affirmative claim that end-users are relevant to the
>> ef

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

2020-09-26 Thread Douglas E. Foster

My apology, Dave, for letting my frustration get the best of me.

Doug Foster

From: Tim Wicinski 
Sent: 9/26/20 12:33 PM
To: fost...@bayviewphysicians.com
Cc: "dmarc@ietf.org" 
Subject: Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender 
Header Field

And here we were getting along so well!

Mr Foster, it's perfectly fine to disagree with Mr Crocker technical points, 
and you are
welcome to have your own opinion on whether he chooses to hear or not.  But 
those opinions should
be kept to yourself.

I see a lot of these heated discussions as a sign that people really care about 
this issue. That's
a good thing.

For the record, I'm a DNS person.  I see most problems as being solved with 
more DNS, or less DNS.
I will say that I have had "passionate discussions" with Mr Crocker on several 
issues and I found that
it was not that he did not listen, but figuring out how to better explain my 
point of view.
Surprisingly to many, he does listen.

Whether this work is in scope for DMARC or not, I would plead guilty for not 
considering this carefully.
In the DNSOP working group I co-chair, *everything* DNS is in scope, until it 
is not in scope.
These types of discussions I was leaning on Seth, Alexey and of course Murray 
the AD.

thanks for listening.
tim

On Sat, Sep 26, 2020 at 8:55 AM Douglas E. Foster 
 wrote:

The problems with your proposal have been well documented, but you apparently 
choose not to hear.   The single paragraph that Scott quoted has multiple 
problems within it.

The group has considered other and better technical proposals (conditional 
signatures, ATSP, RHSWL), but they have all been dropped because the group did 
not believe that Domain Owners would have any desire to implement them, and 
because Mailing List Operators would have no way of knowing which mailing lists 
had implemented the new feature.

If you have solutions to these problems, please put them forward.   Otherwise, 
why are we dragging this back up?

From: Dave Crocker 
Sent: 9/25/20 11:04 PM
To: Scott Kitterman 
Cc: IETF DMARC WG 
Subject: Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender 
Header Field

On 9/25/2020 4:21 PM, Scott Kitterman wrote:On Friday, September 25, 2020 
7:05:22 PM EDT Dave Crocker wrote:I think the obligation to justify is on the 
advocate for change.
That means you are demanding I prove  negative.  Which, of course, is an 
impossible assignment.

Rather, the obligation is on the person claiming the affirmative, which in this 
case means the claim that this proposal somehow 'breaks' or otherwise hurts 
DMARC.

Because the current email protection behavior involves the
RFC5322.From field, and pertain to the human author, it is common to
think that the issue, in protecting the field's content, is behavior
of the human recipient.  However there is no indication that the
enforced values in the RFC5322.From field alter end-user behavior.
In fact there is a long train of indication that it does not.
Rather, the meaningful protections actually operate at the level of
the receiving system's mail filtering engine, which decides on the
dispostion of received mail.

Please provide references for your long train of indications, speaking of
making overly broad assumptions.  If that's accurate, I'd like to understand
the data that tells us that.
I'm not going to do that, because there's a long history of that work being 
ignored, in spite of it being reviewed repeatedly in thse and related fora over 
the years.  It's gotten tiresome to have people claiming an effect that they 
lacks evidence for, and the data to the contrary that they are somehow unaware 
of.

Again, the real requirement is focus on the affirmative.

In this case, an affirmative claim that end-users are relevant to the efficacy 
of DMARC.  I don't recall seeing any research results validating such a view, 
but perhaps I missed it.

Well, ok, here's one that shows lack of efficacy, and it's a big one:  EV-certs

Google to bury indicator for Extended Validation certs in Chrome because users 
barely took notice

https://www.theregister.com/2019/08/12/google_chrome_extended_validation_certificates/

"The reason is simple. "Through our own research as well as a survey of prior 
academic work, the Chrome Security UX team has determined that the EV UI does 
not protect users as intended... users do not appear to make secure choice..."

If this is just an input into an algorithm, then your assertion that you are
only providing another input is supportable, but that's contrary to the DMARC
design.
Perhaps you have not noticed but the demonstrated field use of DMARC, to date, 
tends to be contrary to the design, to the extent anyone thinks that the design 
carries a mandate that receivers follow the directives of the domain owners.

So the text in the draft merely reflects real-world operational styl

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

2020-09-26 Thread John R Levine


On Sat, 26 Sep 2020, John Levine wrote:


In article  you write:

Chairs?


[ something ]


My apologies, that wasn't supposed to go to the list.

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] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field


On 9/26/2020 10:19 AM, John Levine wrote:

I thought he was already in everone's kill file.


John, That's also an ad homen.

d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

2020-09-26 Thread John Levine

In article  you write:
>On 9/26/2020 5:55 AM, Douglas E. Foster wrote:
>> but you apparently choose not to hear. 
>
>
>that's an ad hominem.
>
>Chairs?

I thought he was already in everone's kill file. 

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

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

2020-09-26 Thread Tim Wicinski

And here we were getting along so well!

Mr Foster, it's perfectly fine to disagree with Mr Crocker technical
points, and you are
welcome to have your own opinion on whether he chooses to hear or not.  But
those opinions should
be kept to yourself.

I see a lot of these heated discussions as a sign that people really care
about this issue. That's
a good thing.

For the record, I'm a DNS person.  I see most problems as being solved with
more DNS, or less DNS.
I will say that I have had "passionate discussions" with Mr Crocker on
several issues and I found that
it was not that he did not listen, but figuring out how to better explain
my point of view.
Surprisingly to many, he does listen.

Whether this work is in scope for DMARC or not, I would plead guilty for
not considering this carefully.
In the DNSOP working group I co-chair, *everything* DNS is in scope, until
it is not in scope.
These types of discussions I was leaning on Seth, Alexey and of course
Murray the AD.

thanks for listening.
tim


On Sat, Sep 26, 2020 at 8:55 AM Douglas E. Foster  wrote:

> The problems with your proposal have been well documented, but you
> apparently choose not to hear.   The single paragraph that Scott quoted has
> multiple problems within it.
>
> The group has considered other and better technical proposals (conditional
> signatures, ATSP, RHSWL), but they have all been dropped because the group
> did not believe that Domain Owners would have any desire to implement them,
> and because Mailing List Operators would have no way of knowing which
> mailing lists had implemented the new feature.
>
> If you have solutions to these problems, please put them forward.
> Otherwise, why are we dragging this back up?
>
> --
> *From*: Dave Crocker 
> *Sent*: 9/25/20 11:04 PM
> *To*: Scott Kitterman 
> *Cc*: IETF DMARC WG 
> *Subject*: Re: [dmarc-ietf] Call for Adoption: DMARC Use of the
> RFC5322.Sender Header Field
>
> On 9/25/2020 4:21 PM, Scott Kitterman wrote:
>
> On Friday, September 25, 2020 7:05:22 PM EDT Dave Crocker wrote:
>
> I think the obligation to justify is on the advocate for change.
>
> That means you are demanding I prove  negative.  Which, of course, is an
> impossible assignment.
>
> Rather, the obligation is on the person claiming the affirmative, which in
> this case means the claim that this proposal somehow 'breaks' or otherwise
> hurts DMARC.
>
>
> Because the current email protection behavior involves the
>RFC5322.From field, and pertain to the human author, it is common to
>think that the issue, in protecting the field's content, is behavior
>of the human recipient.  However there is no indication that the
>enforced values in the RFC5322.From field alter end-user behavior.
>In fact there is a long train of indication that it does not.
>   Rather, the meaningful protections actually operate at the level of
>the receiving system's mail filtering engine, which decides on the
>dispostion of received mail.
>
> Please provide references for your long train of indications, speaking of
> making overly broad assumptions.  If that's accurate, I'd like to understand
> the data that tells us that.
>
> I'm not going to do that, because there's a long history of that work
> being ignored, in spite of it being reviewed repeatedly in thse and related
> fora over the years.  It's gotten tiresome to have people claiming an
> effect that they lacks evidence for, and the data to the contrary that they
> are somehow unaware of.
>
> Again, the real requirement is focus on the affirmative.
>
> In this case, an affirmative claim that end-users are relevant to the
> efficacy of DMARC.  I don't recall seeing any research results validating
> such a view, but perhaps I missed it.
>
> Well, ok, here's one that shows lack of efficacy, and it's a big one:
> EV-certs
>
> *Google to bury indicator for Extended Validation certs in Chrome because
> users barely took notice*
>
>
> https://www.theregister.com/2019/08/12/google_chrome_extended_validation_certificates/
>
> "The reason is simple. "Through our own research as well as a survey of
> prior academic work, the Chrome Security UX team has determined that the EV
> UI does not protect users as intended... users do not appear to make secure
> choice..."
>
>
> If this is just an input into an algorithm, then your assertion that you are
> only providing another input is supportable, but that's contrary to the DMARC
> design.
>
> Perhaps you have not noticed but the demonstrated field use of DMARC, to
> date, tends to be contrary to the design, to the extent anyone thinks that
> the design carries a mandate that receivers follow the directives of the
> do

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

2020-09-26 Thread Scott Kitterman

On Friday, September 25, 2020 11:03:51 PM EDT Dave Crocker wrote:
> On 9/25/2020 4:21 PM, Scott Kitterman wrote:
> > On Friday, September 25, 2020 7:05:22 PM EDT Dave Crocker wrote:
> > I think the obligation to justify is on the advocate for change.
> 
> That means you are demanding I prove  negative.  Which, of course, is an
> impossible assignment.
> 
> Rather, the obligation is on the person claiming the affirmative, which
> in this case means the claim that this proposal somehow 'breaks' or
> otherwise hurts DMARC.

I suspect we are going to continue to disagree on this, but I think it's a 
very odd claim that your assertions should be assumed to be correct.

> >  Because the current email protection behavior involves the
> > 
> > RFC5322.From field, and pertain to the human author, it is common to
> > think that the issue, in protecting the field's content, is behavior
> > of the human recipient.  However there is no indication that the
> > enforced values in the RFC5322.From field alter end-user behavior.
> > In fact there is a long train of indication that it does not.
> >
> >Rather, the meaningful protections actually operate at the level of
> >
> > the receiving system's mail filtering engine, which decides on the
> > dispostion of received mail.
> > 
> > Please provide references for your long train of indications, speaking of
> > making overly broad assumptions.  If that's accurate, I'd like to
> > understand the data that tells us that.
> 
> I'm not going to do that, because there's a long history of that work
> being ignored, in spite of it being reviewed repeatedly in thse and
> related fora over the years.  It's gotten tiresome to have people
> claiming an effect that they lacks evidence for, and the data to the
> contrary that they are somehow unaware of.
> 
> Again, the real requirement is focus on the affirmative.
> 
> In this case, an affirmative claim that end-users are relevant to the
> efficacy of DMARC.  I don't recall seeing any research results
> validating such a view, but perhaps I missed it.
> 
> Well, ok, here's one that shows lack of efficacy, and it's a big one: 
> EV-certs
> 
> /Google to bury indicator for Extended Validation certs in Chrome
> because users barely took notice/
> 
> https://www.theregister.com/2019/08/12/google_chrome_extended_validation_cer
> tificates/
> 
> "The reason is simple. "Through our own research as well as a survey of
> prior academic work, the Chrome Security UX team has determined that the
> EV UI does not protect users as intended... users do not appear to make
> secure choice..."
> 
> > If this is just an input into an algorithm, then your assertion that you
> > are only providing another input is supportable, but that's contrary to
> > the DMARC design.
> 
> Perhaps you have not noticed but the demonstrated field use of DMARC, to
> date, tends to be contrary to the design, to the extent anyone thinks
> that the design carries a mandate that receivers follow the directives
> of the domain owners.
> 
> So the text in the draft merely reflects real-world operational style.

I think it's not nearly as clear as you seem to think.  If the standard is 
users will not 100% do the right thing, then I agree that won't happen, but I 
don't think it's a reasonable standard.  I think the standard ought to be that 
there is an overall tendency towards reduced risk.

Somewhat related to your example, these things aren't always entirely 
straightforward:

https://emilymstark.com/2020/07/14/debunking-the-users-always-click-yes-myth.html

However, I suspect we are not going to agree on that either.

Relative to the does this proposal change DMARC question, based on your 
feedback, I think we actually mostly agree.

Any protocol exists in at least two variants:

1.  As documented in specifications such as RFCs

2.  As used in the real world.

Ideally those would be identical, but they never are.

My claim is that this proposal is substantially at odds with the protocol as 
documented (#1).  If I understand your position correctly, you are claiming 
that your proposal is aligned to the protocol as actually used (#2).

Is that correct?

Assuming that it does for a moment to save a round trip on emails:

I think we agree that this proposal is at odds with DMARC as documented.  Is 
it correct that you believe the WG can/should ignore that and focus on DMARC 
as it is used operationally?

Scott K

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

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field


On 9/26/2020 5:55 AM, Douglas E. Foster wrote:
but you apparently choose not to hear. 



that's an ad hominem.

Chairs?

d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field


On 9/26/2020 3:31 AM, Alessandro Vesely wrote:

A pointer to a better aimed report circulated on this list:


An unrefereed presentation (not paper) about a single experiment is 
better than a summary of an industry-wide effort that failed?


And the presentation cited SMTP Mail From, as if that were the important 
field to protect. (And it doesn't even mention DKIM.)


Also, the researchers appear not to know about the issue of co-variates. 
(eg, 21% of their subjects had graduate degrees...)


And, for the current discussion, there's the troublesome summary the 
they give about their own study:



1. Warning only slightly lowers the click rate
2. The absolute click rate is still high


The key words there are "slightly" and "still high".  Prompting the 
question of why anyone would think this study serves as demonstrating 
strong support for the role of end-users in abuse protection?


All of which demonstrates a basic problem with efforts to discuss 
human-related work: difficulties in understanding how to evaluate 
research and research patterns, with a tendency to instead lean on 
confirmation bias.



d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

2020-09-26 Thread Douglas E. Foster

The problems with your proposal have been well documented, but you apparently 
choose not to hear.   The single paragraph that Scott quoted has multiple 
problems within it.

The group has considered other and better technical proposals (conditional 
signatures, ATSP, RHSWL), but they have all been dropped because the group did 
not believe that Domain Owners would have any desire to implement them, and 
because Mailing List Operators would have no way of knowing which mailing lists 
had implemented the new feature.

If you have solutions to these problems, please put them forward.   Otherwise, 
why are we dragging this back up?



From: Dave Crocker 
Sent: 9/25/20 11:04 PM
To: Scott Kitterman 
Cc: IETF DMARC WG 
Subject: Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender 
Header Field

On 9/25/2020 4:21 PM, Scott Kitterman wrote:On Friday, September 25, 2020 
7:05:22 PM EDT Dave Crocker wrote:I think the obligation to justify is on the 
advocate for change.
That means you are demanding I prove  negative.  Which, of course, is an 
impossible assignment.

Rather, the obligation is on the person claiming the affirmative, which in this 
case means the claim that this proposal somehow 'breaks' or otherwise hurts 
DMARC.

Because the current email protection behavior involves the
RFC5322.From field, and pertain to the human author, it is common to
think that the issue, in protecting the field's content, is behavior
of the human recipient.  However there is no indication that the
enforced values in the RFC5322.From field alter end-user behavior.
In fact there is a long train of indication that it does not.
Rather, the meaningful protections actually operate at the level of
the receiving system's mail filtering engine, which decides on the
dispostion of received mail.

Please provide references for your long train of indications, speaking of
making overly broad assumptions.  If that's accurate, I'd like to understand
the data that tells us that.
I'm not going to do that, because there's a long history of that work being 
ignored, in spite of it being reviewed repeatedly in thse and related fora over 
the years.  It's gotten tiresome to have people claiming an effect that they 
lacks evidence for, and the data to the contrary that they are somehow unaware 
of.

Again, the real requirement is focus on the affirmative.

In this case, an affirmative claim that end-users are relevant to the efficacy 
of DMARC.  I don't recall seeing any research results validating such a view, 
but perhaps I missed it.

Well, ok, here's one that shows lack of efficacy, and it's a big one:  EV-certs

Google to bury indicator for Extended Validation certs in Chrome because users 
barely took notice

https://www.theregister.com/2019/08/12/google_chrome_extended_validation_certificates/

"The reason is simple. "Through our own research as well as a survey of prior 
academic work, the Chrome Security UX team has determined that the EV UI does 
not protect users as intended... users do not appear to make secure choice..."

If this is just an input into an algorithm, then your assertion that you are
only providing another input is supportable, but that's contrary to the DMARC
design.
Perhaps you have not noticed but the demonstrated field use of DMARC, to date, 
tends to be contrary to the design, to the extent anyone thinks that the design 
carries a mandate that receivers follow the directives of the domain owners.

So the text in the draft merely reflects real-world operational style.

d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

2020-09-25 Thread Dave Crocker


On 9/25/2020 4:21 PM, Scott Kitterman wrote:

On Friday, September 25, 2020 7:05:22 PM EDT Dave Crocker wrote:
I think the obligation to justify is on the advocate for change. 


That means you are demanding I prove  negative.  Which, of course, is an 
impossible assignment.


Rather, the obligation is on the person claiming the affirmative, which 
in this case means the claim that this proposal somehow 'breaks' or 
otherwise hurts DMARC.




 Because the current email protection behavior involves the
RFC5322.From field, and pertain to the human author, it is common to
think that the issue, in protecting the field's content, is behavior
of the human recipient.  However there is no indication that the
enforced values in the RFC5322.From field alter end-user behavior.
In fact there is a long train of indication that it does not.
   Rather, the meaningful protections actually operate at the level of
the receiving system's mail filtering engine, which decides on the
dispostion of received mail.

Please provide references for your long train of indications, speaking of
making overly broad assumptions.  If that's accurate, I'd like to understand
the data that tells us that.


I'm not going to do that, because there's a long history of that work 
being ignored, in spite of it being reviewed repeatedly in thse and 
related fora over the years.  It's gotten tiresome to have people 
claiming an effect that they lacks evidence for, and the data to the 
contrary that they are somehow unaware of.


Again, the real requirement is focus on the affirmative.

In this case, an affirmative claim that end-users are relevant to the 
efficacy of DMARC.  I don't recall seeing any research results 
validating such a view, but perhaps I missed it.


Well, ok, here's one that shows lack of efficacy, and it's a big one:  
EV-certs


/Google to bury indicator for Extended Validation certs in Chrome 
because users barely took notice/


https://www.theregister.com/2019/08/12/google_chrome_extended_validation_certificates/

"The reason is simple. "Through our own research as well as a survey of 
prior academic work, the Chrome Security UX team has determined that the 
EV UI does not protect users as intended... users do not appear to make 
secure choice..."




If this is just an input into an algorithm, then your assertion that you are
only providing another input is supportable, but that's contrary to the DMARC
design.


Perhaps you have not noticed but the demonstrated field use of DMARC, to 
date, tends to be contrary to the design, to the extent anyone thinks 
that the design carries a mandate that receivers follow the directives 
of the domain owners.


So the text in the draft merely reflects real-world operational style.


d/


--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

2020-09-25 Thread Scott Kitterman

On Friday, September 25, 2020 7:05:22 PM EDT Dave Crocker wrote:
> On 9/25/2020 4:00 PM, Scott Kitterman wrote:
> > In my view the linkage between the identity in From to domains
> > authenticated by DKIM and SPF (d= and mail from) is a fundamental
> > property of DMARC.  If you change that, it's not DMARC anymore.
> 
> It doesn't change that.  It doesn't alter the current use of the From:
> field.
> 
> Mediators might, and so far people have thought that acceptable.
> 
> My suggestion is that you offer some detailed analysis of current
> security-related processing and specify how that will change to the worse.
> 
> The tendency for these topics is for people to make overly-terse,
> overly-broad assertions and conclusions, without any of the detail that
> permits validating the claim.

Sure it does, given what DMARC is.

I think the obligation to justify is on the advocate for change.  Having 
reviewed a large pile of messages from this list to try and catch up, I may 
have missed it, but I haven't seen any justification for this other than you 
claiming it's true:

   Because the current email protection behavior involves the
   RFC5322.From field, and pertain to the human author, it is common to
   think that the issue, in protecting the field's content, is behavior
   of the human recipient.  However there is no indication that the
   enforced values in the RFC5322.From field alter end-user behavior.
   In fact there is a long train of indication that it does not.
  Rather, the meaningful protections actually operate at the level of
   the receiving system's mail filtering engine, which decides on the
   dispostion of received mail.

Please provide references for your long train of indications, speaking of 
making overly broad assumptions.  If that's accurate, I'd like to understand 
the data that tells us that.

If this is just an input into an algorithm, then your assertion that you are 
only providing another input is supportable, but that's contrary to the DMARC 
design.  DMARC is based on an expectation that specific actions ought to be 
taken based on policy [1], which is totally different than what this draft 
proposes. Which, to circle back around, is why I don't think it would be DMARC 
anymore.

Scott K

[1] RFC 7489, Section 6.6.2, Step 6:

   6.  Apply policy.  Emails that fail the DMARC mechanism check are
   disposed of in accordance with the discovered DMARC policy of the
   Domain Owner.  See Section 6.3 for details.

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

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

2020-09-25 Thread Dave Crocker


On 9/25/2020 4:00 PM, Scott Kitterman wrote:

In my view the linkage between the identity in From to domains authenticated
by DKIM and SPF (d= and mail from) is a fundamental property of DMARC.  If you
change that, it's not DMARC anymore.



It doesn't change that.  It doesn't alter the current use of the From: 
field.


Mediators might, and so far people have thought that acceptable.

My suggestion is that you offer some detailed analysis of current 
security-related processing and specify how that will change to the worse.


The tendency for these topics is for people to make overly-terse, 
overly-broad assertions and conclusions, without any of the detail that 
permits validating the claim.



d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

2020-09-25 Thread Scott Kitterman

On Friday, September 25, 2020 5:25:38 PM EDT Dave Crocker wrote:
> On 9/25/2020 1:46 PM, Scott Kitterman wrote:
> >   If something like this is going to be
> > 
> > standardized, it shouldn't be called DMARC because it's not.
> 
> That was cryptic. Please elaborate on your concerns.

In my view the linkage between the identity in From to domains authenticated 
by DKIM and SPF (d= and mail from) is a fundamental property of DMARC.  If you 
change that, it's not DMARC anymore.

Clearer?

Scott K

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

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

2020-09-25 Thread Dave Crocker


On 9/25/2020 1:46 PM, Scott Kitterman wrote:

  If something like this is going to be
standardized, it shouldn't be called DMARC because it's not.


That was cryptic. Please elaborate on your concerns.


d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

2020-09-25 Thread Scott Kitterman

I'm sorry this came up during a period when I wasn't following the list.  
Having caught up recently, I completely agree with the allusions to Sender ID.  
I don't think this his helpful.  If something like this is going to be 
standardized, it shouldn't be called DMARC because it's not.

Scott K

On Friday, September 25, 2020 2:59:42 PM EDT Tim Wicinski wrote:
> Dave Crocker reminded me that we were going to adopt this document as
> Experimental. I was remiss in not mentioning that.
> 
> Even though the WG adopted this document, it was said during the call that
> the WG may not be able to come to a consensus to move the document
> forward.   Adoption does not mean published (see: ARC Usage).
> 
> tim
> 
> On Fri, Sep 25, 2020 at 10:01 AM Tim Wicinski  wrote:
> > All
> > 
> > This call for adoption ended a few weeks ago, I have been recalcitrant in
> > following up.   The chairs feel
> > there is enough consensus to adopt this work in DMARC.   While there were
> > issues raised, the chairs feel
> > they can be addressed through the document process.
> > 
> > thanks
> > tim
> > 
> > 
> > On Mon, Aug 24, 2020 at 2:00 AM Hector Santos  > 
> > 40isdg@dmarc.ietf.org> wrote:
> >> On 8/21/2020 3:09 PM, Jim Fenton wrote:
> >> > On 8/15/20 3:53 PM, John Levine wrote:
> >> >> Assurances that are provided by ADSP are generally obtained out of
> >> 
> >> band in the
> >> 
> >> >> real Internet, and not through ADSP.  Current deployment of ADSP is
> >> >> not
> >> >> recommended.
> >> > 
> >> > Is that not exactly the same situation with DMARC, except that the
> >> > policy in question now is "reject" rather than "discardable"? Yes,
> >> > it's just a keyword, but it reflects the semantics of the expected
> >> > action as well.
> >> > 
> >> > -Jim
> >> 
> >> No one was expected to follow a reject, so it was said, until it did
> >> happen.  SPF pushed
> >> 
> >> --
> >> Hector Santos,
> >> https://secure.santronics.com
> >> https://twitter.com/hectorsantos
> >> 
> >> 
> >> ___
> >> 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] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

2020-09-25 Thread Tim Wicinski

Dave Crocker reminded me that we were going to adopt this document as
Experimental. I was remiss in not mentioning that.

Even though the WG adopted this document, it was said during the call that
the WG may not be able to come to a consensus to move the document
forward.   Adoption does not mean published (see: ARC Usage).

tim


On Fri, Sep 25, 2020 at 10:01 AM Tim Wicinski  wrote:

> All
>
> This call for adoption ended a few weeks ago, I have been recalcitrant in
> following up.   The chairs feel
> there is enough consensus to adopt this work in DMARC.   While there were
> issues raised, the chairs feel
> they can be addressed through the document process.
>
> thanks
> tim
>
>
> On Mon, Aug 24, 2020 at 2:00 AM Hector Santos  40isdg@dmarc.ietf.org> wrote:
>
>> On 8/21/2020 3:09 PM, Jim Fenton wrote:
>>
>> > On 8/15/20 3:53 PM, John Levine wrote:
>> >> Assurances that are provided by ADSP are generally obtained out of
>> band in the
>> >> real Internet, and not through ADSP.  Current deployment of ADSP is not
>> >> recommended.
>>
>> > Is that not exactly the same situation with DMARC, except that the
>> > policy in question now is "reject" rather than "discardable"? Yes,
>> > it's just a keyword, but it reflects the semantics of the expected
>> > action as well.
>> >
>> > -Jim
>>
>> No one was expected to follow a reject, so it was said, until it did
>> happen.  SPF pushed
>>
>> --
>> Hector Santos,
>> https://secure.santronics.com
>> https://twitter.com/hectorsantos
>>
>>
>> ___
>> 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] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

2020-09-25 Thread Tim Wicinski

All

This call for adoption ended a few weeks ago, I have been recalcitrant in
following up.   The chairs feel
there is enough consensus to adopt this work in DMARC.   While there were
issues raised, the chairs feel
they can be addressed through the document process.

thanks
tim


On Mon, Aug 24, 2020 at 2:00 AM Hector Santos  wrote:

> On 8/21/2020 3:09 PM, Jim Fenton wrote:
>
> > On 8/15/20 3:53 PM, John Levine wrote:
> >> Assurances that are provided by ADSP are generally obtained out of band
> in the
> >> real Internet, and not through ADSP.  Current deployment of ADSP is not
> >> recommended.
>
> > Is that not exactly the same situation with DMARC, except that the
> > policy in question now is "reject" rather than "discardable"? Yes,
> > it's just a keyword, but it reflects the semantics of the expected
> > action as well.
> >
> > -Jim
>
> No one was expected to follow a reject, so it was said, until it did
> happen.  SPF pushed
>
> --
> Hector Santos,
> https://secure.santronics.com
> https://twitter.com/hectorsantos
>
>
> ___
> 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] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

2020-08-24 Thread Hector Santos


On 8/21/2020 3:09 PM, Jim Fenton wrote:


On 8/15/20 3:53 PM, John Levine wrote:

Assurances that are provided by ADSP are generally obtained out of band in the
real Internet, and not through ADSP.  Current deployment of ADSP is not
recommended.



Is that not exactly the same situation with DMARC, except that the
policy in question now is "reject" rather than "discardable"? Yes,
it's just a keyword, but it reflects the semantics of the expected
action as well.

-Jim


No one was expected to follow a reject, so it was said, until it did 
happen.  SPF pushed


--
Hector Santos,
https://secure.santronics.com
https://twitter.com/hectorsantos


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

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

2020-08-21 Thread Brandon Long

I think the DMARC RFC does a good job explaining why DMARC is better than
ADSP, even if the same mailing list issue is still there:
https://tools.ietf.org/html/rfc7489#appendix-A.5

And if you read the archives on the move to historic for adsp, there were
others then who objected to the reason put in the historic move as
likely as affecting the replacement .  Given the success of the
replacement, it stands to reason that the reasoning given in the move
to historic was not the full reason for the failure... and perhaps lends
credence to the thought that certain folks are more concerned about the
effects on mailing lists than the ecosystem as a whole is.

Brandon

On Fri, Aug 21, 2020 at 12:10 PM Jim Fenton  wrote:

> On 8/15/20 3:53 PM, John Levine wrote:
>
> Not really. DKIM was deliberately designed not to be tied to any
> visible part of the message. ADSP was a poorly designed hack that was
> never implemented other than small experiments, and that I don't think
> many people understood. I got a lot of grief for making the most
> strict policy "discardable" even though that's obviously what it was.
>
>
> And even with the kinder-and-gentler term "discardable" for its most harsh
> policy option, ADSP was moved from Standards Track to Historic. From
> https://datatracker.ietf.org/doc/status-change-adsp-rfc5617-to-historic/ :
>
> There is, however, evidence of harm caused by incorrect configuration and by
> inappropriate use.  There have, for example, been real cases where a 
> high-value
> domain published an ADSP record of "discardable", but allowed users on their
> domain to subscribe to mailing lists.  When posts from those users were sent 
> to
> other domains that checked ADSP, those subscriber domains rejected the
> messages, resulting in forced unsubscribes from mailman (due to bounces) for
> the unsuspecting subscribers.
>
> Assurances that are provided by ADSP are generally obtained out of band in the
> real Internet, and not through ADSP.  Current deployment of ADSP is not
> recommended.
>
> Is that not exactly the same situation with DMARC, except that the policy
> in question now is "reject" rather than "discardable"? Yes, it's just a
> keyword, but it reflects the semantics of the expected action as well.
>
> -Jim
> ___
> 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] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

2020-08-21 Thread Jim Fenton

On 8/15/20 3:53 PM, John Levine wrote:
> Not really. DKIM was deliberately designed not to be tied to any
> visible part of the message. ADSP was a poorly designed hack that was
> never implemented other than small experiments, and that I don't think
> many people understood. I got a lot of grief for making the most
> strict policy "discardable" even though that's obviously what it was.
>
And even with the kinder-and-gentler term "discardable" for its most
harsh policy option, ADSP was moved from Standards Track to Historic.
From
https://datatracker.ietf.org/doc/status-change-adsp-rfc5617-to-historic/ :

> There is, however, evidence of harm caused by incorrect configuration and by
> inappropriate use.  There have, for example, been real cases where a 
> high-value
> domain published an ADSP record of "discardable", but allowed users on their
> domain to subscribe to mailing lists.  When posts from those users were sent 
> to
> other domains that checked ADSP, those subscriber domains rejected the
> messages, resulting in forced unsubscribes from mailman (due to bounces) for
> the unsuspecting subscribers.
>
> Assurances that are provided by ADSP are generally obtained out of band in the
> real Internet, and not through ADSP.  Current deployment of ADSP is not
> recommended.
Is that not exactly the same situation with DMARC, except that the
policy in question now is "reject" rather than "discardable"? Yes, it's
just a keyword, but it reflects the semantics of the expected action as
well.

-Jim

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

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

2020-08-20 Thread David I

During IETF 108, the chairs realized that there was interest in Dave's
RFC5322.Sender draft.

This starts a Call for Adoption for draft-crocker-dmarc-sender

The draft is available here:
https://datatracker.ietf.org/doc/draft-crocker-dmarc-sender/

Currently, the draft is marked as "Standards Track". The chairs feel if the
working group does adopt this, it should begin as "Experimental". If we start
to see adoption of this work, this can be changed back to "Standards Track"
before
Working Group Last Call. Of course, we welcome input from the working group on
this.

Please review this draft to see if you think it is suitable for adoption, and
send any comments to the list, clearly stating your view.

There's some good thinking in the document, that however leads me to a
different solution space. There are also some bits which aren't clear enough
for me to fully analyse the security impact, and some places where I think it's
lacking.

In a little more detail:
- The reflection that mediators are going to have to implement approaches like
From-rewriting for at least a while leads me to think that standardising From
rewriting is a better way to go. Standardising would allow recipient systems to
undo the From-rewriting if they trust the intermediary and the email is
authenticated (perhaps simple DKIM, perhaps something ARC-related). This has
the benefit that the intermediary doesn't need to worry about whether it's
trusted by the recipient, or whether the recipient has implemented . I agree with everyone who thinks it's somewhat distasteful, but
seems least-worse to me given today's email environment.
- It's not clear to me in the doc which domain is being referred to in various
places. eg assuming From: test@from.example, Sender:
test@sender.example, which domain's DMARC policy
should have the snd tag? If I never add the snd tag to _dmarc.from.example, do
I get to keep today's behaviour?
- It turns a fact based check 'did the DMARC checks pass for the From domain'
to a fuzzier reputation based one. This *may* be similarly effective at scale
against volume spam, though I'm sceptical. I don't believe it's true for
low-volume spear-phishing where 'a few getting through while the reputation
system trains itself' isn't good enough.
- Comparing this to ARC, there's no passing of information about what
authentication checks an intermediary did, nor a statement that an intermediary
should be doing strict DMARC authentication and not passing on things which
fail. That makes the 'trust' decision at a receiver much harder as you don't
know if any authentication has taken place.
- As a reputation/trust based mechanism, it shares weaknesses with ARC -
difficulty of bootstrapping, and favouring large and existing players. So I
don't think it's expanding the solution space much, and risks distracting from
ARC and then running into similar issues.
- The absence of a mechanism to get away from From-rewriting or similar (even
in the long term), means this would be additional complexity with little, if
any practical upside.

Given the above, I don't think this is a fruitful path, so I don't support
adoption at this time.

Regards,
David

This information is exempt under the Freedom of Information Act 2000 (FOIA) and
may be exempt under other UK information legislation. Refer any FOIA queries to
ncscinfo...@ncsc.gov.uk. All material is UK Crown Copyright ©
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

2020-08-19 Thread Laura Atkins



> On 19 Aug 2020, at 00:21, Brandon Long  
> wrote:
> 
> 
> 
> On Mon, Aug 17, 2020 at 5:22 AM Laura Atkins  > wrote:
> 
> 
>> On 17 Aug 2020, at 12:25, Alessandro Vesely > > wrote:
>> 
>> On Mon 17/Aug/2020 11:46:55 +0200 Laura Atkins wrote:
>>> 
>>> The forum page is off the FTC website, but the document links are 
>>> still accessible:
>> 
>> 
>> A copy is here:
>> https://web.archive.org/web/20120603201012/https://www.ftc.gov/bcp/workshops/e-authentication/
>>  
>> 
>> 
>> A sentence says:
>> 
>>The Report, however, identified domain-level authentication as a
>>promising technological development that would enable Internet
>>Service Providers (‘‘ISPs’’) and other domain holders to better
>>filter spam, and that would provide law enforcement with a potent
>>tool for locating and identifying spammers.
> 
> And, 17 years on, we know that domain level authentication doesn’t actually 
> help filter spam nor does it provide law enforcement with a potent tool for 
> locating and identifying spammers. It was promising, it didn’t live up to the 
> promise. 
> 
> I don't understand this.  Virtually every spam rule we write these days 
> depends on information attached to the domain level authentication of an 
> email message.

I was thinking more that simply adding authentication doesn’t do anything to 
identify spam vs. not-spam. Authentication give you a valid identifier to hang 
a reputation on, but spammers are great at implementing authentication.  

> I mean, it's not some simple binary thing, but it also very clearly helps us 
> filter spam.

You are correct and I wasn’t thinking. 

> We know, now, that turning on domain level protection does not stop phishing 
> attacks against that company. It stops direct spoofing of the domain, but the 
> phishers simply use a completely different domain. Just this weekend I got a 
> PayPal phish. PayPal who helped invent DMARC are still getting spoofed and 
> phished. Sure, the phishers aren’t using the paypal..com  
> domain, but that doesn’t seem to have any effect on their success at stealing 
> money from people. 
> 
> Do we have stats on that?

Stats, no. But the fact that they’re still doing it tells me it still works. If 
it wasn’t making them some level of money, they’d move on to something else. 

> I know that we've increased our resources towards anti-phishing over the 
> years, so there's no apples to apples comparison here, and it would be hard 
> to tease out the specifics anyways... but we've certainly had success in 
> catching more of it.

No argument here. But as much of the world’s email you handle you don’t handle 
all of it. And I have spoken with some of the less savory end of mailers who 
actively avoid mailing your network and target folks outside of it. 

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] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

2020-08-17 Thread Murray S. Kucherawy

Still as just me:

On Sat, Aug 15, 2020 at 3:34 PM Douglas E. Foster  wrote:

> Based on the discussions here, it appears that the notion of From address
> validation was envisioned from the beginning Sender Authentication
> discussions.We have written evidence that Form address validation was
> anticipated in the DKIM and ATPS RFCs prior to DMARC.So we have more
> than a decade of warnings that From address validation was coming.   While
> not everybody has time to read every RFC, the Mailing List trade press must
> have should have been reporting on it as something to watch.
>
I don't follow the logic here.  DKIM, as I recall, expressly disavowed any
assertion that could've been taken as From address validation.  (I think it
was in there before RFC 4871, but we collectively decided to remove it.). I
don't know how one could have inferred imminence from that.

ATPS is an Experimental RFC.  It was meant to, in some ways, augment ADSP
when we'd already figured out the damage it could cause.  The purpose of
publishing it was to get everyone (for some value of "everyone") to agree
on a protocol to use to provide third-party signature authorizations and
see if it was a useful response.  The silence was deafening.

Even after DMARC was in use, it appears that nobody in the mailing list
> community felt inconvenienced until the AOL/Yahoo hack and their decision
> to implement DMARC with p=reject.   This was the moment of Unhappy
> Surprise.Bad guys had obtained many valid email addresses, so one of
> the concerns was how to prevent them from spoofing those users to send
> spam.   They could not use those address in the SMTP address because of
> SPF, but only DMARC could prevent those addresses from being misused in the
> Message From address. It was the obvious thing to do and it would have
> been reckless for them to do otherwise.   Can you at least admit that the
> mailing list community was surprised because they failed to prepare for
> this contingency?
>
I wouldn't characterize it as "failure".  If you agree that DMARC's
antecedent is ADSP, I believe it had already fallen into disfavor to the
point where nobody was really worried about it anymore.

But I would agree that nobody anticipated it, especially since DMARC itself
and RFC 6377 both warned against its use for this very reason.

[...]  As a result, mailing list operators really have no standing in this
> discussion, although they can certainly speak as unhappy individual users
> and on behalf of their unhappy users.
>
I suggest that's precisely what gives them standing.

Consequently, the real problem before us becomes the existence of users who
> are unhappy because the From address on some mail does not meet their
> preferences.I have to ask why that is a problem worthy of a standards
> body? I have about 8 different scenarios in my head where a user might
> be have unmet expectations with the format of the From address, or might
> experience mailing list deliverability problems because of the email
> filtering policy of its domain relative to the addressing practices of his
> mailing list.   If our requirement is to make every user happy, shall we
> head down the path of all 8 problems, not just this one?
>
If all eight problems have been raised and acknowledged by the chairs, then
I imagine the answer to your question is emphatically "yes".

Though published as an RFC, DMARC was not an IETF consensus document.  The
remit of this working group is to come to consensus on a set of changes
that qualify it for the standards track.  We do that by considering the
perspectives and issues raised during that process and coming to consensus
on their respective resolutions.


> This project was supposed to discuss moving DMARC from informational to
> standards track.   It has been hijacked by those who, to paraphrase
> Shakespeare, “have not come to praise DMARC, but to bury it.”   This has
> been abetted by the chair’s assertion that we must square a circle – meet
> the MLs requirement for them to impersonate without authorization while
> continuing to advance the DMARC requirement to prohibit impersonation
> without authorization.
> [...]
>
I have not yet seen any assertion that DMARC needs to be buried.  In fact,
revisiting its assumptions is a perfectly feasible way to come to consensus
on its goals and how they might be achieved.  If DMARC was founded on false
premises, that plainly needs to be considered and possibly fixed.  That can
only strengthen it.

None of this discussion seems invalid to me.

As part of that hijacking, we have been inundated by Mr. Crocker’s
> assertions that the message From Address does not matter.  All the years of
> theoretical analysis that preceded DMARC and all of the operational success
> from implementations of DMARC are just wrong, simply because he says so.
>
It's not simply because he says so.  At the time DMARC was on the drawing
board, the MUA game was different.  We talked about this a lot

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field


On 8/17/2020 11:53 AM, Dotzero wrote:

Apology accepted. ;-)


nein.  maaf.

d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

On Mon, Aug 17, 2020 at 2:28 PM Dave Crocker  wrote:

> On 8/17/2020 11:26 AM, Rolf E. Sonneveld wrote:
> >> Michael Hammer (Inaccurately referred to by you as Herr Hammer)
> >
> > Talking about precise language, Dave, I think you owe Michael an apology
> ;-)
>
>
> to mix languages, au contraire.  I was being formal, as well as precise...
>
> d/
>
> --
> Dave Crocker
> Brandenburg InternetWorking
> bbiw.net


Apology accepted. ;-)

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

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

2020-08-17 Thread Rolf E. Sonneveld


>> On 17 Aug 2020, at 16:47, Dotzero  wrote:
> 
> 
> 
>>> On Mon, Aug 17, 2020 at 10:37 AM Dave Crocker  wrote:
> On 8/17/2020 7:33 AM, Dotzero wrote:
 DMARC fixes one thing and one thing only, direct domain abuse.
>>> 
>>> It does no such thing.  Domains can still be 'directly' abused in all sorts 
>>> of ways that DMARC does not affect.  
>>> 
>> 
>> Mea Culpa. You are correct that it only does so in the context of SPF and 
>> DKIM validation which protects rfc5322 From field domains and aligned 
>> rfc5321 Mail From domains (SPF).
>> 
>> 
>> A continuing and in my view fundamental problem with discussion in this 
>> space is the lack of careful and precise language when talking about actions 
>> and effects.
>> 
>> 
>> 
>> So...
>> 
>> DMARC fixes abuse of rfc5322.From field domains.  
>> 
>> THAT is the only thing it does.
>> 
> See above.. I was even more specific than you were in terms of what DMARC 
> does. 
>> And it does it at the expense of breaking some legitimate uses.
>> 
> Only when it is used in domains where there are individual user accounts and 
> not (only) transactional mail uses. If I use a hammer (no pun intended) to 
> pound in a screw, it doesn't make it the right tool for the job.
> 
> Michael Hammer (Inaccurately referred to by you as Herr Hammer)

Talking about precise language, Dave, I think you owe Michael an apology ;-)

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

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

On Mon 17/Aug/2020 16:00:42 +0200 Laura Atkins wrote:
>> On 17 Aug 2020, at 14:18, Dotzero  wrote:
>>
>>
>> You raise an interesting point, Laura. Whatever "solutions" we put in place, 
>> the abusers/bad guys will evolve. One of the problems for the good guys (for 
>> some definition of good) is that standards work takes years (decades?)  
>> while the bad  guys change their tactics at will. Crime existed before the 
>> Internet and will continue long after we are all dead and buried.
> 
> Totally agreed. The issue here is that DMARC is a fundamentally flawed model 
> for preventing phishing. Phishers were adapting to mailbox provider filters 
> even before DMARC and there was a lot of cousin and non-look-alike domain 
> phishing even during the initial discussions. I know these issues were 
> brought up during discussion of the protocol. Unfortunately, they weren’t 
> sufficiently addressed and now we’re at a point where, to my mind, DMARC 
> doesn’t fix anything while also breaking a lot of ways folks use mail.
> 
> It’s a little late now to go back.


That's what I meant by being stuck midstream.  Neither forward nor backward...


> I think this is an opportunity to think about the underlying technical 
> problems as well as a chance to revisit the assumptions about how email is 
> used. Discussing things like Dave’s drafts will give us a chance to talk 
> about how people actually use email to communicate with one another. And how 
> we can allow brands what they want without breaking email too much for the 
> rest of us.


We have to fix the defects that cause DMARC collateral damage, if I may so 
roughly summarize our charter.  We have two ways to do that:

Forward:  Solve each specific problem.  For example, apply dkim-transform to 
MLM messages.

Backward:  Kill DMARC expansion.  For example, reaffirm that domains which host 
personal mailboxes must not publish strict policies.


Best
Ale
-- 





















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

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field


On Mon 17/Aug/2020 14:48:31 +0200 Dotzero wrote:

On Sun, Aug 16, 2020 at 2:03 PM Alessandro Vesely  wrote:


Gmail has a visual perspective that allows them to know each and every
email domain worldwide, and employs a number of people who help
continuously upgrading domain reputation.  In order to enjoy such
technology, medium-small domains can get a G Suite account.  That's
oligopoly.  If the technology were simpler and clearer, running one's
own mail server could be a valid alternative.



Setting aside DMARC, running email servers has always had a bit of
complexity that is beyond the ability of the average person. I'm not sure
what your point here is.



Having very many autonomous MTAs is better than oligopoly, from a 
dynamic social stability point of view.  As spam elimination is the 
most prominent complexity that cause giving up private MTAs, global 
DMARC adoption might have the potential to stabilize communications.



Best
Ale
--


































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

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

On Mon, Aug 17, 2020 at 10:37 AM Dave Crocker  wrote:

> On 8/17/2020 7:33 AM, Dotzero wrote:
>
> DMARC fixes one thing and one thing only, direct domain abuse.
>
>
> It does no such thing.  Domains can still be 'directly' abused in all
> sorts of ways that DMARC does not affect.
>

Mea Culpa. You are correct that it only does so in the context of SPF and
DKIM validation which protects rfc5322 From field domains and aligned
rfc5321 Mail From domains (SPF).

> 
>
> A continuing and in my view fundamental problem with discussion in this
> space is the lack of careful and precise language when talking about
> actions and effects.
>
> 
>
> So...
>
> DMARC fixes abuse of rfc5322.From field domains.
>
> THAT is the only thing it does.
>
See above. I was even more specific than you were in terms of what DMARC
does.

> And it does it at the expense of breaking some legitimate uses.
>
Only when it is used in domains where there are individual user accounts
and not (only) transactional mail uses. If I use a hammer (no pun intended)
to pound in a screw, it doesn't make it the right tool for the job.

Michael Hammer (Inaccurately referred to by you as Herr Hammer)
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

On Mon, Aug 17, 2020 at 10:27 AM Dave Crocker  wrote:

> On 8/17/2020 7:00 AM, Laura Atkins wrote:
>
> I think the most
>  useful thing we can say about the FTC workshops is that they were a
> forcing mechanism that instigated a lot of effort and innovation in the
> space. Some of those efforts fell by the wayside and some still persist.
>
>
> You think? I’m not sure I’d agree. I saw the workshop as mostly a
> political (and educating the politicians) exercise. The effort and
> innovation were already there and being done by a lot of people who weren’t
> there. I’m kinda bemused by the importance folks have assigned to it in
> relation to the vastly different email ecosystem we have today.
>
>
> This might be quibbling, but I think it kicked a bit more energy into the
> anti-abuse industry.  So, as a moment to mark in time, it I think it was
> useful.  But no, not fundamentally for the creation and development of
> email anti-abuse work.
>
> d/
>

Exactly. +1

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

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field


On 8/17/2020 7:33 AM, Dotzero wrote:

DMARC fixes one thing and one thing only, direct domain abuse.



It does no such thing.  Domains can still be 'directly' abused in all 
sorts of ways that DMARC does not affect.




   A continuing and in my view fundamental problem with discussion in
   this space is the lack of careful and precise language when talking
   about actions and effects.



So...

DMARC fixes abuse of rfc5322.From field domains.

THAT is the only thing it does.

And it does it at the expense of breaking some legitimate uses.

d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

On Mon, Aug 17, 2020 at 10:01 AM Laura Atkins 
wrote:

>
>
> On 17 Aug 2020, at 14:18, Dotzero  wrote:
>
>>
>> And, 17 years on, we know that domain level authentication doesn’t
>> actually help filter spam nor does it provide law enforcement with a potent
>> tool for locating and identifying spammers. It was promising, it didn’t
>> live up to the promise.
>>
>> There were a lot of thrown at the wall during those 3 days of talks. One
>> of them was domain level opt-out. Another was a global opt-out list similar
>> to the postal opt-outs run by the DMA. Another was a technology called
>> TEOS. HashCash. The list of things we discussed as promising solutions was
>> extensive. Just because we discussed a particular kind of solution does not
>> mean that anything was decided. It also doesn’t mean that any particular
>> solution mentioned was workable.
>>
>>
>> https://www.ftc.gov/sites/default/files/documents/public_events/ftc-spam-forum/transcript_day1.pdf
>>
>> https://www.ftc.gov/sites/default/files/documents/public_events/ftc-spam-forum/transcript_day2.pdf
>> 
>>
>> https://www.ftc.gov/sites/default/files/documents/public_events/ftc-spam-forum/transcript_day3.pdf
>>
>>
>>
>> Thanks.  Let me quote a paragraph by Paul Q. Judge, from the 3rd pdf:
>>
>>It doesn't require that one day everyone turns it on and we begin
>>to drop the rest of the e-mail and break e-mail.  If a domain
>>decides to turn it on, then they've prevented forgery for their
>>domain and they're protected.  For persons that have not turned it
>>on, then their e-mail still flows but they are not able to
>>stop people from forging messages from their domain.  So, I think
>>it's something useful and can be deployed incrementally.
>>
>>
>> We know, now, that turning on domain level protection does not stop
>> phishing attacks against that company. It stops direct spoofing of the
>> domain, but the phishers simply use a completely different domain. Just
>> this weekend I got a PayPal phish. PayPal who helped invent DMARC are still
>> getting spoofed and phished. Sure, the phishers aren’t using the
>> paypal.com domain, but that doesn’t seem to have any effect on their
>> success at stealing money from people.
>>
>
> You raise an interesting point, Laura. Whatever "solutions" we put in
> place, the abusers/bad guys will evolve. One of the problems for the good
> guys (for some definition of good) is that standards work takes years
> (decades?)  while the bad  guys change their tactics at will. Crime existed
> before the Internet and will continue long after we are all dead and buried.
>
>
> Totally agreed. The issue here is that DMARC is a fundamentally flawed
> model for preventing phishing. Phishers were adapting to mailbox provider
> filters even before DMARC and there was a lot of cousin and non-look-alike
> domain phishing even during the initial discussions. I know these issues
> were brought up during discussion of the protocol. Unfortunately, they
> weren’t sufficiently addressed and now we’re at a point where, to my mind,
> DMARC doesn’t fix anything while also breaking a lot of ways folks use mail.
>
>
DMARC fixes one thing and one thing only, direct domain abuse. Not cousin
domains, not homoglyphs and not a whole bunch of other things. It
was successful in achieving its intended purpose. It was initially
developed and deployed privately as a "private club". The intent in making
it a public standard was to enable any domain, regardless of size or
connections to be able to participate if that domain needed to fight direct
domain abuse, noting the caveats regarding individual user accounts vs
transactional email.

It’s a little late now to go back. I think this is an opportunity to think
> about the underlying technical problems as well as a chance to revisit the
> assumptions about how email is used. Discussing things like Dave’s drafts
> will give us a chance to talk about how people actually use email to
> communicate with one another. And how we can allow brands what they want
> without breaking email too much for the rest of us.
>
> It seems we're still stuck midstream...
>>
>>
>> Stuck at what? Many of the people who were at that conference are still
>> working in the field and understand both the purpose and what came out of
>> the forum. I’d also say that most of what happened there is a nice bit of
>> history but is also irrelevant to addressing the spam problem as it is now.
>> Email has evolved significantly in the last 5 years, much less the last 15.
>> We can use the discussion as history to say “we looked at this and it
>> didn’t work” but I don’t really see a lot of value in saying “let’s retread
>> things from a decade and a half ago that didn’t work.”
>>
>
> I think the most
>  useful thing we can say about the FTC workshops is that they were a
> forcing mechanism that instigated a lot of

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field


On 8/17/2020 7:00 AM, Laura Atkins wrote:

I think the most
 useful thing we can say about the FTC workshops is that they were a 
forcing mechanism that instigated a lot of effort and innovation in 
the space. Some of those efforts fell by the wayside and some still 
persist.


You think? I’m not sure I’d agree. I saw the workshop as mostly a 
political (and educating the politicians) exercise. The effort and 
innovation were already there and being done by a lot of people who 
weren’t there. I’m kinda bemused by the importance folks have assigned 
to it in relation to the vastly different email ecosystem we have today.




This might be quibbling, but I think it kicked a bit more energy into 
the anti-abuse industry.  So, as a moment to mark in time, it I think it 
was useful.  But no, not fundamentally for the creation and development 
of email anti-abuse work.


d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field



> On 17 Aug 2020, at 14:18, Dotzero  wrote:
> 
> And, 17 years on, we know that domain level authentication doesn’t actually 
> help filter spam nor does it provide law enforcement with a potent tool for 
> locating and identifying spammers. It was promising, it didn’t live up to the 
> promise. 
> 
> There were a lot of thrown at the wall during those 3 days of talks. One of 
> them was domain level opt-out. Another was a global opt-out list similar to 
> the postal opt-outs run by the DMA. Another was a technology called TEOS. 
> HashCash. The list of things we discussed as promising solutions was 
> extensive. Just because we discussed a particular kind of solution does not 
> mean that anything was decided. It also doesn’t mean that any particular 
> solution mentioned was workable. 
> 
>>> https://www.ftc.gov/sites/default/files/documents/public_events/ftc-spam-forum/transcript_day1.pdf
>>>  
>>> 
>>> https://www.ftc.gov/sites/default/files/documents/public_events/ftc-spam-forum/transcript_day2.pdf
>>>  
>>> 
>>> https://www.ftc.gov/sites/default/files/documents/public_events/ftc-spam-forum/transcript_day3.pdf
>>>  
>>> 
>> 
>> 
>> Thanks.  Let me quote a paragraph by Paul Q. Judge, from the 3rd pdf:
>> 
>>It doesn't require that one day everyone turns it on and we begin
>>to drop the rest of the e-mail and break e-mail.  If a domain
>>decides to turn it on, then they've prevented forgery for their
>>domain and they're protected.  For persons that have not turned it
>>on, then their e-mail still flows but they are not able to
>>stop people from forging messages from their domain.  So, I think
>>it's something useful and can be deployed incrementally.
> 
> We know, now, that turning on domain level protection does not stop phishing 
> attacks against that company. It stops direct spoofing of the domain, but the 
> phishers simply use a completely different domain. Just this weekend I got a 
> PayPal phish. PayPal who helped invent DMARC are still getting spoofed and 
> phished. Sure, the phishers aren’t using the paypal.com  
> domain, but that doesn’t seem to have any effect on their success at stealing 
> money from people. 
> 
> You raise an interesting point, Laura. Whatever "solutions" we put in place, 
> the abusers/bad guys will evolve. One of the problems for the good guys (for 
> some definition of good) is that standards work takes years (decades?)  while 
> the bad  guys change their tactics at will. Crime existed before the Internet 
> and will continue long after we are all dead and buried.

Totally agreed. The issue here is that DMARC is a fundamentally flawed model 
for preventing phishing. Phishers were adapting to mailbox provider filters 
even before DMARC and there was a lot of cousin and non-look-alike domain 
phishing even during the initial discussions. I know these issues were brought 
up during discussion of the protocol. Unfortunately, they weren’t sufficiently 
addressed and now we’re at a point where, to my mind, DMARC doesn’t fix 
anything while also breaking a lot of ways folks use mail.

It’s a little late now to go back. I think this is an opportunity to think 
about the underlying technical problems as well as a chance to revisit the 
assumptions about how email is used. Discussing things like Dave’s drafts will 
give us a chance to talk about how people actually use email to communicate 
with one another. And how we can allow brands what they want without breaking 
email too much for the rest of us. 

>> It seems we're still stuck midstream...
> 
> Stuck at what? Many of the people who were at that conference are still 
> working in the field and understand both the purpose and what came out of the 
> forum. I’d also say that most of what happened there is a nice bit of history 
> but is also irrelevant to addressing the spam problem as it is now. Email has 
> evolved significantly in the last 5 years, much less the last 15. We can use 
> the discussion as history to say “we looked at this and it didn’t work” but I 
> don’t really see a lot of value in saying “let’s retread things from a decade 
> and a half ago that didn’t work.”
> 
> I think the most 
>  useful thing we can say about the FTC workshops is that they were a forcing 
> mechanism that instigated a lot of effort and innovation in the space. Some 
> of those efforts fell by the wayside and some still persist.

You think? I’m not sure I’d agree. I saw the workshop as mostly a political 
(and educating the politicians) exercise. The effort and innovation were 
already there and being done by a lot of people who weren’t there. I’m kinda 
bemused by the importance

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

2020-08-17 Thread Joseph Brennan

On Mon, Aug 17, 2020 at 6:24 AM Laura Atkins 
wrote:

>
>
> The DMARC proponents have asserted that DMARC prevents domain specific
> spoofing and phishing. The amount of harm DMARC authentication has caused,
> however, seems disproportional to this small benefit. Phishing is still
> happening using cousin domains (and even random domains). Departments
> inside companies avoid DMARC mandates buy buying cousin and “campaign
> specific” domains which trains users to be phishing targets for those
> domains. Companies have tried to cut down on this by saying DMARC must be
> done for all those domains as well. Unfortunately, those “from above”
> decrees have often created more problems than they solved.
>
> Mailing lists have coped by rewriting from addresses, but that has caused
> a lot of issues. Two of the big ones are members can no longer search for
> “mail from this list member” and cannot easily create filters acting on
> mail from other participants.
>

Well said (I liked the poetic indentation too)

The fact is that DMARC has disrupted the flow of ordinary legitimate email.
Actors not involved or interested in DMARC have had to spend time and money
developing ways to work around DMARC in order to keep mailing lists and
forwarding working, or else they have had to spend time and money on the
alternative of informing their customers that legitimate practices they
have done for years no longer work reliably and have to be discontinued.

Adding more complexity does not make a broken thing less broken. I think
the proposed standard should simply spell out in plain words that the
purpose of DMARC is to protect transactional mail, e.g. about bank and
credit accounts or purchase confirmations, and that it is not for mail from
ordinary end users. Given that I think more sending systems would be
willing to publish p=reject and more receiving systems would be willing to
honor it. It won't be the end of spoofs, but it would reduce the disruption
to people outside the DMARC club.

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

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

On Mon, Aug 17, 2020 at 8:22 AM Laura Atkins 
wrote:

>
>
> On 17 Aug 2020, at 12:25, Alessandro Vesely  wrote:
>
> On Mon 17/Aug/2020 11:46:55 +0200 Laura Atkins wrote:
>
>
> The forum page is off the FTC website, but the document links are
> still accessible:
>
>
>
> A copy is here:
>
> https://web.archive.org/web/20120603201012/https://www.ftc.gov/bcp/workshops/e-authentication/
>
> A sentence says:
>
>The Report, however, identified domain-level authentication as a
>promising technological development that would enable Internet
>Service Providers (‘‘ISPs’’) and other domain holders to better
>filter spam, and that would provide law enforcement with a potent
>tool for locating and identifying spammers.
>
>
> And, 17 years on, we know that domain level authentication doesn’t
> actually help filter spam nor does it provide law enforcement with a potent
> tool for locating and identifying spammers. It was promising, it didn’t
> live up to the promise.
>
> There were a lot of thrown at the wall during those 3 days of talks. One
> of them was domain level opt-out. Another was a global opt-out list similar
> to the postal opt-outs run by the DMA. Another was a technology called
> TEOS. HashCash. The list of things we discussed as promising solutions was
> extensive. Just because we discussed a particular kind of solution does not
> mean that anything was decided. It also doesn’t mean that any particular
> solution mentioned was workable.
>
>
> https://www.ftc.gov/sites/default/files/documents/public_events/ftc-spam-forum/transcript_day1.pdf
>
> https://www.ftc.gov/sites/default/files/documents/public_events/ftc-spam-forum/transcript_day2.pdf
>
> https://www.ftc.gov/sites/default/files/documents/public_events/ftc-spam-forum/transcript_day3.pdf
>
>
>
> Thanks.  Let me quote a paragraph by Paul Q. Judge, from the 3rd pdf:
>
>It doesn't require that one day everyone turns it on and we begin
>to drop the rest of the e-mail and break e-mail.  If a domain
>decides to turn it on, then they've prevented forgery for their
>domain and they're protected.  For persons that have not turned it
>on, then their e-mail still flows but they are not able to
>stop people from forging messages from their domain.  So, I think
>it's something useful and can be deployed incrementally.
>
>
> We know, now, that turning on domain level protection does not stop
> phishing attacks against that company. It stops direct spoofing of the
> domain, but the phishers simply use a completely different domain. Just
> this weekend I got a PayPal phish. PayPal who helped invent DMARC are still
> getting spoofed and phished. Sure, the phishers aren’t using the
> paypal.com domain, but that doesn’t seem to have any effect on their
> success at stealing money from people.
>

You raise an interesting point, Laura. Whatever "solutions" we put in
place, the abusers/bad guys will evolve. One of the problems for the good
guys (for some definition of good) is that standards work takes years
(decades?)  while the bad  guys change their tactics at will. Crime existed
before the Internet and will continue long after we are all dead and buried..

> It seems we're still stuck midstream...
>
>
> Stuck at what? Many of the people who were at that conference are still
> working in the field and understand both the purpose and what came out of
> the forum. I’d also say that most of what happened there is a nice bit of
> history but is also irrelevant to addressing the spam problem as it is now.
> Email has evolved significantly in the last 5 years, much less the last 15.
> We can use the discussion as history to say “we looked at this and it
> didn’t work” but I don’t really see a lot of value in saying “let’s retread
> things from a decade and a half ago that didn’t work.”
>

I think the most
 useful thing we can say about the FTC workshops is that they were a
forcing mechanism that instigated a lot of effort and innovation in the
space. Some of those efforts fell by the wayside and some still persist.

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

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field


On 8/17/2020 2:57 AM, Alessandro Vesely wrote:
Reference to that event as if it 'established' anything is misguided, 
at best.  The meetings were helpful, but not definitive.  And the 
efforts at domain level authentication were wholly independent of 
these events.



Would it be still correct to mention that summit as a conspicuous event 
that testifies the emergence of domain-level authentication around the 
early 2000s?


No.


d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

On Mon, Aug 17, 2020 at 5:58 AM Alessandro Vesely  wrote:

> On Sun 16/Aug/2020 20:16:17 +0200 Dave Crocker wrote:
> >
> > If I put my gmail address into the from field, there is no
> > pretending, no matter what platform I am using.
> 
> 
>  That conflicts with the coarse-grained authentication strategy,
>  established at the FTC Email Authentication Summit in November
>  2004, as Doug^W Michael recalled >>>
> >>> 1. I was making a semantic point, not a technical or technical
> >>> policy one.
> >>
> >> They have to match at some point.
> >
> > it would be nice, wouldn't it?
> >
> > but that's separate from the factual statement I made.
>
>
> Separate but related.
>
>
> >>> 2. There was nothing 'established' at that event.  There were
> >>> interesting discussions, but that's all.
> >>
> >>
> >> I wasn't there.  Can't it be considered the historic event that
> >> marked domain-level authentication as the promising strategy to
> >> counter email abuse?
> >
> > Reference to that event as if it 'established' anything is misguided,
> > at best.  The meetings were helpful, but not definitive.  And the
> > efforts at domain level authentication were wholly independent of
> > these events.
>
>
> Would it be still correct to mention that summit as a conspicuous
> event that testifies the emergence of domain-level authentication
> around the early 2000s?
>
>
As someone who was there, I would be reticent to make such a statement.

>
> > As already noted on this list, the events served as a plea from the
> > government and, therefore, a signal that the government was concerned.
>
>
> A noteworthy historical detail.
>

I think myself and many others considered it more of an ultimatum to the
private sector than a plea.

>
>
>  Your gmail address needs to be authenticated by gmail.
> >>>
> >>> Good grief, no.  There is no system rule to that effect.  DMARC
> >>> created that, but no policy before it was in place, never mind
> >>> accepted.
> >>
> >>
> >> DMARC took that strategy to the extremes.  A number of users and
> >> operators seem to have accepted it.  Why cannot we accept it too?
> >
> > That DMARC does something and that some people use it is quite
> > different from claiming that there was some grand change in the
> > semantics and operational policy of email.  Why can't THAT be accepted?
>

I think this is one of those areas that where you sit dictates where you
stand on the issue. When we talk about the evolution of the Internet we
could also go back to the days of AUP and talk about changes. Just saying.


>
> There's been a combination of events, from IETF's reluctant
> laissez-faire to Yahoo/AOL adoption, which brought up the illusion
> that email authentication can provide a global means to counter
> spoofing.  To believe that such illusion will come true makes for a
> strong motivation.
>

We really do need to stop using the word "spoofing" when we talk about
intermediaries such as MLMs.

>
> Couldn't we meet somewhere halfway?  I can see that you, John, Herr
> Hammer, and other relevant participants don't accept that domain-level
> authentication is semantically mandatory.  What d'you reckon about the
> possibility that such grand semantic change can be made official
> within the next 10~20 years?  I think that by just spelling the
> technical means /as if/ such change is going to happen, we can design
> a consistent authentication protocol.
>

Could people please stop referring to me as Herr Hammer. I am neither
German nor a Herr.


> It seems to me most expenses have been paid already, for example this
> mailing list is applying From: rewriting.  We don't need to propose
> further restrictions.  To the opposite, there are means on the
> table[*] that can enable us to sketch a time horizon where From:
> rewriting can cease.
>
> 16 years have passed since the FTC event, which is 1/3 of those 45.
> What I see looks much like a very mild shift.  Lazy operators have
> plenty of time before the semantic change is established, at some
> point in the medium-term future, if ever.
>

Notwithstanding my position on the issues being discussed, I think it is
unfair and inappropriate to refer to those opposed to changing semantics as
"lazy operators". Just because you want a change and they are against such
change does not make them lazy.

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

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

On Sun, Aug 16, 2020 at 2:17 PM John R Levine  wrote:

>
> No, it was just some political theatre.  We were already working on SPF
> and DKIM.
>

DKIM didn't exist  until that approximate time frame. There was Domain
Keys (DK) and there was Internet Identified Mail (IIM)

>
> > DMARC took that strategy to the extremes.  A number of users and
> operators
> > seem to have accepted it.  Why cannot we accept it too?
>
> Please review the previous bazillion messages on this topic.
>

Are those bazillion messages authenticated? ;-)

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

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

On Sun, Aug 16, 2020 at 2:03 PM Alessandro Vesely  wrote:

>
> >> That conflicts with the coarse-grained authentication strategy,
> >> established at the FTC Email Authentication Summit in November
> >> 2004, as Doug^W Michael recalled. >
>
> There was no such strategy established regardless of what one person
remembers.

>
>
>
> > 2. There was nothing 'established' at that event.  There were
> > interesting discussions, but that's all.
>

Agreed.

>
>
> I wasn't there.  Can't it be considered the historic event that marked
> domain-level authentication as the promising strategy to counter email
> abuse?
>

Nope. It was one of many things presented/disccussed.

>
> https://mailarchive.ietf.org/arch/msg/dmarc/-pX7yWlSk39ShOjAzWMxhxlKh1E
>
>
> >> Your gmail address needs to be authenticated by gmail.
> >
> > Good grief, no.  There is no system rule to that effect.  DMARC
> > created that, but no policy before it was in place, never mind accepted.
>

Just to reiterate, DMARC, SPF and DKIM operate at the domain level
granularity, not at the individual email address level granularity.

>
>
> DMARC took that strategy to the extremes.  A number of users and
> operators seem to have accepted it.  Why cannot we accept it too?
>

DMARC does one thing and one thing only, and that is to mitigate direct
domain abuse. It was not intended to stop phishing, spam or anything but
direct domain abuse. The issues with uses such as mailing lists were
identified and noted.

>
>
> >> Sending From: bbiw.net, SPF-authenticated as dcrocker.net, and
> >> whitelisted as yet another domain (songbird.com) can hardly be
> >> verified.  There is no "pretending", since it's you, but it is not
> >> formally distinguishable from spoof, is it?
> >
> > Whether valid and invalid uses can be distinguished does not alter the
> > fact that valid uses are valid.
>
>
> The problem is to find the technical means that allow receivers and
> recipients to verify such validity.
>
>
> >>> This continuing practice of characterizing valid use as if it were
> >>> spoofing or pretending has been a major impediment to constructive
> >>> discussion in the industry.
> >>
> >> A system that is able to recognize all your domains and affiliations
> >> in order to authenticate messages does cost several orders of
> >> magnitude more than a simple "mechanical" verifier.  That way,
> >> requiring too much flexibility is a push toward oligopoly.
> >
> > I have no idea what you are referring it.
>
>
> Gmail has a visual perspective that allows them to know each and every
> email domain worldwide, and employs a number of people who help
> continuously upgrading domain reputation.  In order to enjoy such
> technology, medium-small domains can get a G Suite account.  That's
> oligopoly.  If the technology were simpler and clearer, running one's
> own mail server could be a valid alternative.
>

Setting aside DMARC, running email servers has always had a bit of
complexity that is beyond the ability of the average person. I'm not sure
what your point here is.

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

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

On Sun, Aug 16, 2020 at 11:31 AM Dave Crocker  wrote:

>
>
> 2. There was nothing 'established' at that event.  There were
> interesting discussions, but that's all.
>

In fact, some of the most interesting discussions took place outside the
formal event.

>
> 3. I'm not finding the reference in any of Doug's notes that your are
> relying on.  Please be specific about it.
>
>
> > Doug recalled.  Your gmail address needs to be authenticated by gmail.
>
> Good grief, no.  There is no system rule to that effect.  DMARC created
> that, but no policy before it was in place, nevermind accepted.
>

We need to be very careful in asserting what DMARC does or does not do.
DMARC does not prevent spoofing within an email domain. So continuing the
gmail example, DMARC would not prevent dcroc...@gmail.com from pretending
to be dotz...@gmail.com within the gmail system. There are other mechanisms
for preventing this, but DMARC is not that solution.

>
>
> > Sending From: bbiw.net, SPF-authenticated as dcrocker.net, and
> > whitelisted as yet another domain (songbird.com) can hardly be
> > verified.  There is no "pretending", since it's you, but it is not
> > formally distinguishable from spoof, is it?
>
> Whether valid and invalid uses can be distinguished does not alter the
> fact that valid uses are valid.
>

What are valid uses constitutes a key part of the discussion.  At one end
of the discussion is "We have always done it this way so go away". At the
other end of the discussion is "Tough noogies, thing change". An
interesting question is who gets to determine what is a valid use? Another
aspect is whether such determinations are technical, political, legal,
social or ? Part of the difficulty we are having with our discussions here
is that people are conflating the various aspects of the problem space.

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

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

> On 17 Aug 2020, at 12:25, Alessandro Vesely  wrote:
> 
> On Mon 17/Aug/2020 11:46:55 +0200 Laura Atkins wrote:
>> 
>> The forum page is off the FTC website, but the document links are 
>> still accessible:
> 
> 
> A copy is here:
> https://web.archive.org/web/20120603201012/https://www.ftc.gov/bcp/workshops/e-authentication/
> 
> A sentence says:
> 
>The Report, however, identified domain-level authentication as a
>promising technological development that would enable Internet
>Service Providers (‘‘ISPs’’) and other domain holders to better
>filter spam, and that would provide law enforcement with a potent
>tool for locating and identifying spammers.

And, 17 years on, we know that domain level authentication doesn’t actually 
help filter spam nor does it provide law enforcement with a potent tool for 
locating and identifying spammers. It was promising, it didn’t live up to the 
promise. 

There were a lot of thrown at the wall during those 3 days of talks. One of 
them was domain level opt-out. Another was a global opt-out list similar to the 
postal opt-outs run by the DMA. Another was a technology called TEOS. HashCash. 
The list of things we discussed as promising solutions was extensive. Just 
because we discussed a particular kind of solution does not mean that anything 
was decided. It also doesn’t mean that any particular solution mentioned was 
workable. 

>> https://www.ftc.gov/sites/default/files/documents/public_events/ftc-spam-forum/transcript_day1.pdf
>> https://www.ftc.gov/sites/default/files/documents/public_events/ftc-spam-forum/transcript_day2.pdf
>> https://www.ftc.gov/sites/default/files/documents/public_events/ftc-spam-forum/transcript_day3.pdf
> 
> 
> Thanks.  Let me quote a paragraph by Paul Q. Judge, from the 3rd pdf:
> 
>It doesn't require that one day everyone turns it on and we begin
>to drop the rest of the e-mail and break e-mail.  If a domain
>decides to turn it on, then they've prevented forgery for their
>domain and they're protected.  For persons that have not turned it
>on, then their e-mail still flows but they are not able to
>stop people from forging messages from their domain.  So, I think
>it's something useful and can be deployed incrementally.

We know, now, that turning on domain level protection does not stop phishing 
attacks against that company. It stops direct spoofing of the domain, but the 
phishers simply use a completely different domain. Just this weekend I got a 
PayPal phish. PayPal who helped invent DMARC are still getting spoofed and 
phished. Sure, the phishers aren’t using the paypal.com  
domain, but that doesn’t seem to have any effect on their success at stealing 
money from people. 

> It seems we're still stuck midstream...

Stuck at what? Many of the people who were at that conference are still working 
in the field and understand both the purpose and what came out of the forum. 
I’d also say that most of what happened there is a nice bit of history but is 
also irrelevant to addressing the spam problem as it is now. Email has evolved 
significantly in the last 5 years, much less the last 15. We can use the 
discussion as history to say “we looked at this and it didn’t work” but I don’t 
really see a lot of value in saying “let’s retread things from a decade and a 
half ago that didn’t work.”

laura

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

-- 
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] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

On Mon 17/Aug/2020 11:46:55 +0200 Laura Atkins wrote:
> 
> The forum page is off the FTC website, but the document links are 
> still accessible:

A copy is here:
https://web.archive.org/web/20120603201012/https://www.ftc.gov/bcp/workshops/e-authentication/

A sentence says:

The Report, however, identified domain-level authentication as a
promising technological development that would enable Internet
Service Providers (‘‘ISPs’’) and other domain holders to better
filter spam, and that would provide law enforcement with a potent
tool for locating and identifying spammers.

> https://www.ftc.gov/sites/default/files/documents/public_events/ftc-spam-forum/transcript_day1.pdf
> https://www.ftc.gov/sites/default/files/documents/public_events/ftc-spam-forum/transcript_day2.pdf
> https://www.ftc.gov/sites/default/files/documents/public_events/ftc-spam-forum/transcript_day3.pdf

Thanks.  Let me quote a paragraph by Paul Q. Judge, from the 3rd pdf:

It doesn't require that one day everyone turns it on and we begin
to drop the rest of the e-mail and break e-mail.  If a domain
decides to turn it on, then they've prevented forgery for their
domain and they're protected.  For persons that have not turned it
on, then their e-mail still flows but they are not able to
stop people from forging messages from their domain.  So, I think
it's something useful and can be deployed incrementally.

It seems we're still stuck midstream...

Best
Ale
-- 

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

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field



> On 17 Aug 2020, at 10:57, Alessandro Vesely  wrote:
> 
> On Sun 16/Aug/2020 20:16:17 +0200 Dave Crocker wrote:
>> If I put my gmail address into the from field, there is no pretending, 
>> no matter what platform I am using.
> 
> 
> That conflicts with the coarse-grained authentication strategy, 
> established at the FTC Email Authentication Summit in November
> 2004, as Doug^W Michael recalled >>>
 1. I was making a semantic point, not a technical or technical policy one.
>>> 
>>> They have to match at some point.
>> it would be nice, wouldn't it?
>> but that's separate from the factual statement I made.
> 
> 
> Separate but related.
> 
> 
 2. There was nothing 'established' at that event.  There were interesting 
 discussions, but that's all.
>>> 
>>> 
>>> I wasn't there.  Can't it be considered the historic event that marked 
>>> domain-level authentication as the promising strategy to counter email 
>>> abuse?
>> Reference to that event as if it 'established' anything is misguided, at 
>> best.  The meetings were helpful, but not definitive.  And the efforts at 
>> domain level authentication were wholly independent of these events.
> 
> 
> Would it be still correct to mention that summit as a conspicuous event that 
> testifies the emergence of domain-level authentication around the early 2000s?

As someone who participated in the forum, that is not how I’d characterize it 
at all. You can read 

>> As already noted on this list, the events served as a plea from the 
>> government and, therefore, a signal that the government was concerned.
> 
> A noteworthy historical detail.

Maybe? This was part of the drafting of CAN SPAM. If you look at what CAN SPAM 
was concerned with, authentication didn’t show up. 

> 
> Your gmail address needs to be authenticated by gmail. 
 
 Good grief, no.  There is no system rule to that effect.  DMARC created 
 that, but no policy before it was in place, never mind accepted.
>>> 
>>> 
>>> DMARC took that strategy to the extremes.  A number of users and operators 
>>> seem to have accepted it.  Why cannot we accept it too?
>> That DMARC does something and that some people use it is quite different 
>> from claiming that there was some grand change in the semantics and 
>> operational policy of email.  Why can't THAT be accepted?
> 
> 
> There's been a combination of events, from IETF's reluctant laissez-faire to 
> Yahoo/AOL adoption, which brought up the illusion that email authentication 
> can provide a global means to counter spoofing.  To believe that such 
> illusion will come true makes for a strong motivation.
> 
> Couldn't we meet somewhere halfway?  I can see that you, John, Herr Hammer, 
> and other relevant participants don't accept that domain-level authentication 
> is semantically mandatory.  What d'you reckon about the possibility that such 
> grand semantic change can be made official within the next 10~20 years?  I 
> think that by just spelling the technical means /as if/ such change is going 
> to happen, we can design a consistent authentication protocol.

What issue will only domain-level authentication solve? 

The DMARC proponents have asserted that DMARC prevents domain specific spoofing 
and phishing. The amount of harm DMARC authentication has caused, however, 
seems disproportional to this small benefit. Phishing is still happening using 
cousin domains (and even random domains). Departments inside companies avoid 
DMARC mandates buy buying cousin and “campaign specific” domains which trains 
users to be phishing targets for those domains. Companies have tried to cut 
down on this by saying DMARC must be done for all those domains as well. 
Unfortunately, those “from above” decrees have often created more problems than 
they solved. 

Mailing lists have coped by rewriting from addresses, but that has caused a lot 
of issues. Two of the big ones are members can no longer search for “mail from 
this list member” and cannot easily create filters acting on mail from other 
participants. 

laura 

> Sending From: bbiw.net, SPF-authenticated as dcrocker.net, and 
> whitelisted as yet another domain (songbird.com) can hardly be verified.  
> There is no "pretending", since it's you, but it is not formally 
> distinguishable from spoof, is it?
 
 Whether valid and invalid uses can be distinguished does not alter the 
 fact that valid uses are valid.
>>> 
>>> The problem is to find the technical means that allow receivers and 
>>> recipients to verify such validity.
>> Of course.  But when it's at the expense of valid use that has worked for 45 
>> years, then those means are problematic.  Highly.
> 
> It seems to me most expenses have been paid already, for example this mailing 
> list is applying From: rewriting.  We don't need to propose further 
> restrictions.  To the opposite, there are means on the table[*] that can 
> enable us to sketch a time horizon

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field


On Sun 16/Aug/2020 20:16:17 +0200 Dave Crocker wrote:


If I put my gmail address into the from field, there is no 
pretending, no matter what platform I am using.



That conflicts with the coarse-grained authentication strategy, 
established at the FTC Email Authentication Summit in November

2004, as Doug^W Michael recalled >>>
1. I was making a semantic point, not a technical or technical 
policy one.


They have to match at some point.


it would be nice, wouldn't it?

but that's separate from the factual statement I made.



Separate but related.


2. There was nothing 'established' at that event.  There were 
interesting discussions, but that's all.



I wasn't there.  Can't it be considered the historic event that 
marked domain-level authentication as the promising strategy to 
counter email abuse?


Reference to that event as if it 'established' anything is misguided, 
at best.  The meetings were helpful, but not definitive.  And the 
efforts at domain level authentication were wholly independent of 
these events.



Would it be still correct to mention that summit as a conspicuous 
event that testifies the emergence of domain-level authentication 
around the early 2000s?



As already noted on this list, the events served as a plea from the 
government and, therefore, a signal that the government was concerned.



A noteworthy historical detail.


Your gmail address needs to be authenticated by gmail. 


Good grief, no.  There is no system rule to that effect.  DMARC 
created that, but no policy before it was in place, never mind 
accepted.



DMARC took that strategy to the extremes.  A number of users and 
operators seem to have accepted it.  Why cannot we accept it too?


That DMARC does something and that some people use it is quite 
different from claiming that there was some grand change in the 
semantics and operational policy of email.  Why can't THAT be accepted?



There's been a combination of events, from IETF's reluctant 
laissez-faire to Yahoo/AOL adoption, which brought up the illusion 
that email authentication can provide a global means to counter 
spoofing.  To believe that such illusion will come true makes for a 
strong motivation.


Couldn't we meet somewhere halfway?  I can see that you, John, Herr 
Hammer, and other relevant participants don't accept that domain-level 
authentication is semantically mandatory.  What d'you reckon about the 
possibility that such grand semantic change can be made official 
within the next 10~20 years?  I think that by just spelling the 
technical means /as if/ such change is going to happen, we can design 
a consistent authentication protocol.



Sending From: bbiw.net, SPF-authenticated as dcrocker.net, and 
whitelisted as yet another domain (songbird.com) can hardly be 
verified.  There is no "pretending", since it's you, but it is not 
formally distinguishable from spoof, is it?


Whether valid and invalid uses can be distinguished does not alter 
the fact that valid uses are valid.


The problem is to find the technical means that allow receivers and 
recipients to verify such validity.


Of course.  But when it's at the expense of valid use that has worked 
for 45 years, then those means are problematic.  Highly.



It seems to me most expenses have been paid already, for example this 
mailing list is applying From: rewriting.  We don't need to propose 
further restrictions.  To the opposite, there are means on the 
table[*] that can enable us to sketch a time horizon where From: 
rewriting can cease.


16 years have passed since the FTC event, which is 1/3 of those 45. 
What I see looks much like a very mild shift.  Lazy operators have 
plenty of time before the semantic change is established, at some 
point in the medium-term future, if ever.



Best
Ale
--

[*] For MLMs to resume traditional address usage, the most promising 
I-D's is dkim-transform, IMHO.































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

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field



> On 16 Aug 2020, at 19:16, John R Levine  wrote:
> 
> On Sun, 16 Aug 2020, Alessandro Vesely wrote:
> If I put my gmail address into the from field, there is no pretending, no 
> matter what platform I am using.
 That conflicts with the coarse-grained authentication strategy, 
 established at the FTC Email Authentication Summit in November
 2004, as Doug^W Michael recalled. >
>>> 1. I was making a semantic point, not a technical or technical policy one.
>> 
>> They have to match at some point.
> 
> Sorry, that's just wrong.  There's no technical reason a mail message can't 
> have any identifiers the sender wants.
> 
>>> 2. There was nothing 'established' at that event.  There were interesting 
>>> discussions, but that's all.
>> 
>> I wasn't there.  Can't it be considered the historic event that marked 
>> domain-level authentication as the promising strategy to counter email abuse?
> 
> No, it was just some political theatre.  We were already working on SPF and 
> DKIM.

I don’t remember much focus on domain-level authentication at the event. 
Authentication was one small piece of the discussion but not even a focus. My 
recollection is that the 3 days were mostly about scoping the spam problem, not 
solving it. 

The forum page is off the FTC website, but the document links are still 
accessible: 

https://www.ftc.gov/sites/default/files/documents/public_events/ftc-spam-forum/transcript_day1.pdf
 

https://www.ftc.gov/sites/default/files/documents/public_events/ftc-spam-forum/transcript_day2.pdf
 

https://www.ftc.gov/sites/default/files/documents/public_events/ftc-spam-forum/transcript_day3.pdf
 



>> DMARC took that strategy to the extremes.  A number of users and operators 
>> seem to have accepted it.  Why cannot we accept it too?
> 
> Please review the previous bazillion messages on this topic.

There’s a difference between accepting it and working around the damage it 
causes to let users continue to use mailing lists. Consumer mailbox providers 
deciding their users couldn’t participate in mailing lists was and is a 
problem. Companies preventing their employees from participating in work 
related forums was and is a problem. 

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] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

2020-08-16 Thread John R Levine


On Sun, 16 Aug 2020, Alessandro Vesely wrote:
If I put my gmail address into the from field, there is no pretending, no 
matter what platform I am using.


That conflicts with the coarse-grained authentication strategy, 
established at the FTC Email Authentication Summit in November

2004, as Doug^W Michael recalled. >

1. I was making a semantic point, not a technical or technical policy one.


They have to match at some point.


Sorry, that's just wrong.  There's no technical reason a mail message 
can't have any identifiers the sender wants.


2. There was nothing 'established' at that event.  There were interesting 
discussions, but that's all.


I wasn't there.  Can't it be considered the historic event that marked 
domain-level authentication as the promising strategy to counter email abuse?


No, it was just some political theatre.  We were already working on SPF 
and DKIM.


DMARC took that strategy to the extremes.  A number of users and operators 
seem to have accepted it.  Why cannot we accept it too?


Please review the previous bazillion messages on this topic.

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] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

2020-08-16 Thread Dave Crocker



If I put my gmail address into the from field, there is no 
pretending, no matter what platform I am using.



That conflicts with the coarse-grained authentication strategy, 
established at the FTC Email Authentication Summit in November

2004, as Doug^W Michael recalled. >
1. I was making a semantic point, not a technical or technical policy 
one.



They have to match at some point.


it would be nice, wouldn't it?

but that's separate from the factual statement I made.


2. There was nothing 'established' at that event.  There were 
interesting discussions, but that's all.



I wasn't there.  Can't it be considered the historic event that marked 
domain-level authentication as the promising strategy to counter email 
abuse?


Reference to that event as if it 'established' anything is misguided, at 
best.  The meetings were helpful, but not definitive.  And the efforts 
at domain level authentication were wholly independent of these events.


As already noted on this list, the events served as a plea from the 
government and, therefore, a signal that the government was concerned.




3. I'm not finding the reference in any of Doug^X Michael's notes
that your are relying on.  Please be specific about it.



https://mailarchive.ietf.org/arch/msg/dmarc/-pX7yWlSk39ShOjAzWMxhxlKh1E


Finally found that you meant Herr Hammer.


Your gmail address needs to be authenticated by gmail. 


Good grief, no.  There is no system rule to that effect.  DMARC 
created that, but no policy before it was in place, never mind accepted.



DMARC took that strategy to the extremes.  A number of users and 
operators seem to have accepted it.  Why cannot we accept it too?


That DMARC does something and that some people use it is quite different 
from claiming that there was some grand change in the semantics and 
operational policy of email.  Why can't THAT be accepted?





Sending From: bbiw.net, SPF-authenticated as dcrocker.net, and 
whitelisted as yet another domain (songbird.com) can hardly be 
verified.  There is no "pretending", since it's you, but it is not 
formally distinguishable from spoof, is it?


Whether valid and invalid uses can be distinguished does not alter the 
fact that valid uses are valid.


The problem is to find the technical means that allow receivers and 
recipients to verify such validity.


Of course.  But when it's at the expense of valid use that has worked 
for 45 years, then those means are problematic.  Highly.


d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field


On Sun 16/Aug/2020 17:31:47 +0200 Dave Crocker wrote:

On 8/16/2020 1:23 AM, Alessandro Vesely wrote:

On Sat 15/Aug/2020 20:12:18 +0200 Dave Crocker wrote:

On 8/15/2020 3:32 AM, Alessandro Vesely wrote:


If X pretends to be Y,



If I put my gmail address into the from field, there is no 
pretending, no matter what platform I am using.



That conflicts with the coarse-grained authentication strategy, 
established at the FTC Email Authentication Summit in November

2004, as Doug^W Michael recalled. >
1. I was making a semantic point, not a technical or technical policy 
one.



They have to match at some point.


2. There was nothing 'established' at that event.  There were 
interesting discussions, but that's all.



I wasn't there.  Can't it be considered the historic event that marked 
domain-level authentication as the promising strategy to counter email 
abuse?




3. I'm not finding the reference in any of Doug^X Michael's notes
that your are relying on.  Please be specific about it.



https://mailarchive.ietf.org/arch/msg/dmarc/-pX7yWlSk39ShOjAzWMxhxlKh1E


Your gmail address needs to be authenticated by gmail. 


Good grief, no.  There is no system rule to that effect.  DMARC 
created that, but no policy before it was in place, never mind accepted.



DMARC took that strategy to the extremes.  A number of users and 
operators seem to have accepted it.  Why cannot we accept it too?



Sending From: bbiw.net, SPF-authenticated as dcrocker.net, and 
whitelisted as yet another domain (songbird.com) can hardly be 
verified.  There is no "pretending", since it's you, but it is not 
formally distinguishable from spoof, is it?


Whether valid and invalid uses can be distinguished does not alter the 
fact that valid uses are valid.



The problem is to find the technical means that allow receivers and 
recipients to verify such validity.



This continuing practice of characterizing valid use as if it were 
spoofing or pretending has been a major impediment to constructive 
discussion in the industry.


A system that is able to recognize all your domains and affiliations 
in order to authenticate messages does cost several orders of 
magnitude more than a simple "mechanical" verifier.  That way, 
requiring too much flexibility is a push toward oligopoly.


I have no idea what you are referring it.



Gmail has a visual perspective that allows them to know each and every 
email domain worldwide, and employs a number of people who help 
continuously upgrading domain reputation.  In order to enjoy such 
technology, medium-small domains can get a G Suite account.  That's 
oligopoly.  If the technology were simpler and clearer, running one's 
own mail server could be a valid alternative.



Best
Ale
--

























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

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

2020-08-16 Thread John R Levine

If I put my gmail address into the from field, there is no pretending, no 
matter what platform I am using.


That conflicts with the coarse-grained authentication strategy, established 
at the FTC Email Authentication Summit in November 2004, ...


No, it doesn't.  It probably won't surprise you to hear that several of us 
were there.


The FTC wanted a way to reliably associate a domain name with a message, 
and they gave SPF and Domainkeys and Sender-ID as examples.  The IETF 
later published SPF and DKIM (which is a tweaked version of Domainkeys), 
as standard track RFCs each of which associate a domain name with a 
message.


They all use a domain name in different places in the message; only 
Sender-ID used the From header address, and even then only if there was no 
Sender, or Resent-From, or Resent-Sender.  (That was the infamous PRA 
patent.)


It wasn't until DMARC came along that anything formalized the unfortunate 
misapprehension that the From header address is the only "real" identity.


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] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

2020-08-16 Thread Dave Crocker


On 8/16/2020 1:23 AM, Alessandro Vesely wrote:
On Sat 15/Aug/2020 20:12:18 +0200 Dave Crocker wrote:> On 8/15/2020 3:32 
AM, Alessandro Vesely wrote:



If X pretends to be Y,



If I put my gmail address into the from field, there is no pretending, 
no matter what platform I am using.



That conflicts with the coarse-grained authentication strategy, 
established at the FTC Email Authentication Summit in November 2004, as 


1. I was making a semantic point, not a technical or technical policy one.

2. There was nothing 'established' at that event.  There were 
interesting discussions, but that's all.


3. I'm not finding the reference in any of Doug's notes that your are 
relying on.  Please be specific about it.



Doug recalled.  Your gmail address needs to be authenticated by gmail. 


Good grief, no.  There is no system rule to that effect.  DMARC created 
that, but no policy before it was in place, nevermind accepted.



Sending From: bbiw.net, SPF-authenticated as dcrocker.net, and 
whitelisted as yet another domain (songbird.com) can hardly be 
verified.  There is no "pretending", since it's you, but it is not 
formally distinguishable from spoof, is it?


Whether valid and invalid uses can be distinguished does not alter the 
fact that valid uses are valid.



This continuing practice of characterizing valid use as if it were 
spoofing or pretending has been a major impediment to constructive 
discussion in the industry.


A system that is able to recognize all your domains and affiliations in 
order to authenticate messages does cost several orders of magnitude 
more than a simple "mechanical" verifier.  That way, requiring too much 
flexibility is a push toward oligopoly.


I have no idea what you are referring it.

d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field


On Sun 16/Aug/2020 04:18:56 +0200 John Levine wrote:

In article  you write:


This morning I had a conversation with the CEO of a company that
was hit by ransomware which arrived with the help of a single
email.   He is slowly getting his company back after paying a lot
of money to people who want to destroy us. >

I think you would be dismayed how little of that would be stopped
by more stringent DMARC policies. They use lookalike addresses, or
they depend on MUAs that show the From header comments rather than
the addresses. I once saw a very slick spear phish where the crook 
registered the victim's domain name substituting "rn" for "m".


Lookalike domains are also being addressed by browser developers.  It 
is the obvious next-thing-to-do.  Those algorithms could be ported to 
MUAs, except that it's pretty useless to seal the windows when the 
roof is still under construction.



Best
Ale
--



























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

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field


On Sun 16/Aug/2020 10:23:45 +0200 I wrote:

FTC Email Authentication Summit in November 2004, as Doug recalled.



Sorry, of course I meant Michael.


Best
Ale
--












































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

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field