Re: [dmarc-ietf] draft-crocker-dmarc-author-00 ?

[Jesse Thompson]

On 8/17/20 3:00 PM, Luis E. Muñoz wrote:
> DMARC can be quite useful even with p=none.

Agreed.  People commonly request that we accept-list their IP/domain from 
inbound spam scanning.  We now tell them to send DMARC-aligned mail (SPF or 
DKIM pass, aligned with From), and we'll use that as criteria to accept mail 
from the domain, regardless of what policy they actually publish.

Jesse

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

Re: [dmarc-ietf] draft-crocker-dmarc-author-00 ?

[Neil Anuskiewicz]

On Mon, Aug 17, 2020 at 1:00 PM Luis E. Muñoz  wrote:

> On 14 Aug 2020, at 12:47, Neil Anuskiewicz wrote:
> >  Under 50% of companies have any DMARC record. Of those who deploy
> > DMARC,
> > about ~2% have p=quarantine and ~5% p=reject, though some industries
> > such
> > as finance it looks like it's closer to 15% p=reject. I'm sure these
> > numbers aren't perfect but what you have likely isn't radically
> > different.
>
> My numbers are inverted regarding quarantine vs reject, as I posted on
> this list:
>
> On 30 Jul 2020, at 18:01, Luis E. Muñoz wrote:
> >
> > I am currently observing ~215.5 million domain names. Out of those,
> > ~64  million have a seemingly _valid_ SPF record and ~113 million with
> > at least one MX record.
> >
> > This is a current breakdown of the (valid) DMARC records I am
> > observing over the general domain population above. This amounts to an
> > adoption rate of ~1.7%.
> >
> > |p   |  count  |
> > | :- | --: |
> > | none   | 2715614 |
> > | quarantine |  238584 |
> > | reject |  726045 |
>
> Numbers have moved a bit since then, but not much. I'm seeing 3:1 reject
> to quarantine ratio across the board.
>
> > Why is adoption low? Is that a big problem? Why so few aggressive
> > policies?
> > Is that a big problem?
>
> DMARC can be quite useful even with p=none. This use case provides
> insight on what's going on and sometimes, that's all that is wanted.
> Moving to more aggressive policies require a degree of control on the
> mail flows that not all organizations are prepared to exercise, IMO.
>
> Yes, I completely agree, p=none is useful. It's helped me help the client
(I'm basically an IT freelancer) make sure all their email sources' DKIM
and SPF's squared away. More interesting, DMARC's found things that have
surprised clients. Wait, who's using ESP X? Some detective work and a few
days later... Okay, it's the such and such office or sometimes even
individuals. And there's oh right we do use Y. Let's get that authenticated..

So it's legit sources that need to be authenticated, semi-legit sources
that either need to be authenticated and viewed as fully legit or told to
stop and there's sources that are legit but have been running on autopilot.
Let's think about whether we need this or what changes we can make to it.
This aspect serves as a sort of internal audit of email sources and
authentication. DMARC's been very, very useful for that.

Then there's discovering spoofing sometimes, of course.

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

Re: [dmarc-ietf] draft-crocker-dmarc-author-00 ?

[John Levine]

In article <543E391F-800B-4DAD-9310-B6D121AD0FEA@lem.click> you write:
>> Why is adoption low? Is that a big problem? Why so few aggressive 
>> policies? Is that a big problem?
>
>DMARC can be quite useful even with p=none. This use case provides 
>insight on what's going on and sometimes, that's all that is wanted. 
>Moving to more aggressive policies require a degree of control on the 
>mail flows that not all organizations are prepared to exercise, IMO.

Quite right. My system publishes DMARC policies for over 100 domains,
and they're all p=none execpt that four which don't send mail at all
have p=reject.

I collect and look at the reports which can be very interesting.

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

Re: [dmarc-ietf] draft-crocker-dmarc-author-00 ?

[Luis E. Muñoz]

On 14 Aug 2020, at 12:47, Neil Anuskiewicz wrote:
 Under 50% of companies have any DMARC record. Of those who deploy 
DMARC,
about ~2% have p=quarantine and ~5% p=reject, though some industries 
such

as finance it looks like it's closer to 15% p=reject. I'm sure these
numbers aren't perfect but what you have likely isn't radically 
different.


My numbers are inverted regarding quarantine vs reject, as I posted on 
this list:


On 30 Jul 2020, at 18:01, Luis E. Muñoz wrote:


I am currently observing ~215.5 million domain names. Out of those, 
~64  million have a seemingly _valid_ SPF record and ~113 million with 
at least one MX record.


This is a current breakdown of the (valid) DMARC records I am 
observing over the general domain population above. This amounts to an 
adoption rate of ~1.7%.


|p   |  count  |
| :- | --: |
| none   | 2715614 |
| quarantine |  238584 |
| reject |  726045 |


Numbers have moved a bit since then, but not much. I'm seeing 3:1 reject 
to quarantine ratio across the board.


Why is adoption low? Is that a big problem? Why so few aggressive 
policies?

Is that a big problem?


DMARC can be quite useful even with p=none. This use case provides 
insight on what's going on and sometimes, that's all that is wanted. 
Moving to more aggressive policies require a degree of control on the 
mail flows that not all organizations are prepared to exercise, IMO.


Best regards

-lem

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

Re: [dmarc-ietf] draft-crocker-dmarc-author-00 ?

[Dave Crocker]

On 8/15/2020 3:59 PM, John R Levine wrote:

On Sat, 15 Aug 2020, Dave Crocker wrote:
My comment was not about your opinion of either of the drafts but of 
your impatience with considering one you don't like.


Um, if one thinks something is a bad idea, why should we spend more time 
on it?



Out of respect for others who might disagree with you and others who 
might not have formed their opinion yet.


d/


--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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

Re: [dmarc-ietf] draft-crocker-dmarc-author-00 ?

[John R Levine]

On Sat, 15 Aug 2020, Dave Crocker wrote:

On 8/15/2020 12:48 PM, John Levine wrote:

Also, I'm sorry to hear that the wg isn't capable of discussing two
drafts at the same time.
I'm pretty sure that my opinions about -author and -sender would be the 
same even if they'd been published a year apart.


John -- your response is oddly orthongonal to my comment.

My comment was not about your opinion of either of the drafts but of your 
impatience with considering one you don't like.


Um, if one thinks something is a bad idea, why should we spend more time 
on it?


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] draft-crocker-dmarc-author-00 ?

[Dave Crocker]

On 8/15/2020 12:48 PM, John Levine wrote:

Also, I'm sorry to hear that the wg isn't capable of discussing two
drafts at the same time.

I'm pretty sure that my opinions about -author and -sender would be the same
even if they'd been published a year apart.



John -- your response is oddly orthongonal to my comment.

My comment was not about your opinion of either of the drafts but of 
your impatience with considering one you don't like.


d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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

Re: [dmarc-ietf] draft-crocker-dmarc-author-00 ?

[John Levine]

In article <603b1699-6a99-0fc3-3fc8-a037126a7...@dcrocker.net> you write:
>Also, I'm sorry to hear that the wg isn't capable of discussing two 
>drafts at the same time.

I'm pretty sure that my opinions about -author and -sender would be the same
even if they'd been published a year apart.

R's,
John

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

Re: [dmarc-ietf] draft-crocker-dmarc-author-00 ?

[Dave Crocker]

On 8/12/2020 1:09 PM, John Levine wrote:

Let's work on your Sender draft which doesn't try to change what MUAs display.



and which won't fully fix the user-level problems, because... legacy DMARC.

Also, I'm sorry to hear that the wg isn't capable of discussing two 
drafts at the same time.


d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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

Re: [dmarc-ietf] draft-crocker-dmarc-author-00 ?

[Dave Crocker]

On 8/13/2020 2:38 PM, Kurt Andersen (b) wrote:
Passing DMARC is not a be-all-end-all. That's what local policy is 
for. I fail to see why local policy would not solve your problem (as 
described).



We tend to use the term 'local policy' to refer to exceptional behavior.

(I'm not suggesting you were, but am using your reference to it as an 
excuse to make this small rant.)


Receiving filtering engines do whatever they want.  Always. Always 
have.  No outside agency or actor or standard affects that fact at all.


Rather, outside agencies, actors, and standards merely provide input to 
that filtering engine.


"Local policy" is always and entirely in charge of what happens 
locally.  Everything else is subservient.


d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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

Re: [dmarc-ietf] draft-crocker-dmarc-author-00 ?

[Dave Crocker]

Steve, et al,

On 8/12/2020 8:16 AM, Steve Atkins wrote:

On 12/08/2020 04:32, Dave Crocker wrote:

Here's why I think it won't:  They already have From:.

The real value in DMARC is not what is displayed to the end-user but 
in having a required field that cites the originating domain name.  
That doesn't change if there are additional fields that might or 
might not mention the originating domain.


I think we disagree on the goal of DMARC. The entire point of DMARC is 
brand protection.


Yes, but...

High-level goals are fine.  But then they meet lower-level technical and 
operational pragmatics.


For its originally-intended use, DMARC linked high and low pretty well.

The expanded use doesn't and essentially was adopted more to do with 
stemming a denial of service attack.




Control over what is displayed to the user,


I'm confused.  I thought this was a technical forum, not a marketing forum.

User's typically don't see the email address and typically it won't 
matter if they do.  And this has been pointed out repeatedly.


So while, yes, these have driven many people's thinking, that thinking 
isn't based on empirical realities.


In this forum, we should not have to constantly be reminded that, in 
actual practice, none of these activities involve direct user behavior.  
Operationally, they are only relevant to the receiving filtering engine.


To the extent someone wants to claim otherwise, they should produce 
empirical evidence, not summaries of marketing views. (And this request 
also should not need this constant repetition.)



not what's in any particular header. You could use it for other 
things, but that's what informed publishers of DMARC say they're using 
it for (sometimes phrased as "protection against phishing" but that 
too is all about what's displayed to the recipient).


No doubt. But, really, there is no closed-loop mechanism to validate 
that it is achieving what they think it is for, namely getting users to 
make fewer bad decisions about their mail content.


Certainly unauthorized use of a domain name in the From: field 
/correlates/ positively and perfectly with an assessment of spam, but it 
correlates negatively and perfectly with authorized uses, such as 
mailing lists.


So in statistical terms, folk using DMARC see utility, but that's as a 
detector of some spam, and not other spam. And they are dismissive of 
the negatives, because it doesn't affect /them/.



The tone that seems to permeate here is that we need to prevent any new 
identity -- addressing -- fields  because bad actors will abuse them.


What this misses is whether that abuse matters.  I realize that it 
bothers us to see such abuse, but whether the abuse matters ought to be 
relevant.



If you display the contents of Author to the user, then DMARC 
publishers will want to control that.


So we need to cater to folk who want to do things that have no empirical 
validity?  Seems a poor basis for technical work.


The reason the Author: field is being proposed is to regain 
author-to-recipient MUA-level utility.


Also there's the small matter of anticipating strategic behavior of 
operators without actually knowing that the anticipation is correct and 
having no history of such behavior other than a single, problematic data 
point.  As I recall, DMARC uptake is a small percentage of the industry. 
That makes invocation of a predicted industry behavior also problematic.



If MUAs will display the contents of the Author: header where the 
From: header is now then draft-crocker-dmarc-author-00 effectively 
moves what used to be Sender: header to the From: header and what used 
to be the From: header to the Author: header.


As I keep noting, that is what DMARC has already done.

It breaks basic, author-related utility of the From: field for MUA use.  
That should matter.


And the -sender- proposal can't fix that. (see below)


You could achieve exactly the same result, with much less deployment 
effort, by updating DMARC to enforce the Sender header and leaving 
MUAs displaying the From: header. That wouldn't be acceptable to 
anyone who wants to publish DMARC, so the Author: proposal won't be 
either. 


It would be nice for that to be as effective as folk want to believe, 
but it can't.


1. Sender is an optional field.  DMARC needs something that is always 
present.  That's really why there was no choice other than From:, for 
its original design.


2. DMARC has an installed base and the 'legacy' receiving engines need 
to be able to operate with DMARC without having to convert ot use of the 
Sender: field.  I tried to find a way to make this work and failed, 
which is why the current -sender- draft works in parallel to the From: 
field, rather than taking precedence over it.



d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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

Re: [dmarc-ietf] draft-crocker-dmarc-author-00 ?

[Kurt Andersen (b)]

On Fri, Aug 14, 2020 at 12:16 PM Jim Fenton  wrote:

> On 8/14/20 11:30 AM, Kurt Andersen (b) wrote:
>
> On Fri, Aug 14, 2020 at 9:23 AM Dotzero  wrote:
>
>>
>>  Is this an interoperability problem that is solved by IETF standards or
>> is it an organizational problem that requires an organizational solution?
>> Perhaps we need to generate an RFC entitled "Don't Do Stupid Things". ;-)
>>
>
> I think that it might be out of the DMARC-WG's charter, but such an RFC
> would be eminently quotable along with 2549 and other such work.
>
> We already have a number of such RFCs:
>
>
> https://datatracker.ietf.org/doc/search?name=considered+harmful==on=on=group=
>
> -Jim
>
Maybe we should write _Implementing Email Security Without Understanding
What You Are Doing Is Considered Harmful_ - that could fall within our
remit.

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

Re: [dmarc-ietf] draft-crocker-dmarc-author-00 ?

[Neil Anuskiewicz]

On Fri, Aug 14, 2020 at 11:15 AM Dotzero  wrote:

>
>
> On Fri, Aug 14, 2020 at 1:32 PM Neil Anuskiewicz 
> wrote:
>
>>
>>
>> On Fri, Aug 14, 2020 at 8:13 AM Kurt Andersen (b) 
>> wrote:
>>
>>> On Fri, Aug 14, 2020 at 7:31 AM Dotzero  wrote:
>>>

 I've been involved in setting up DMARC with a policy of p=reject for
 somewhere North of 6,000 domains. As a sending domain, the heavy lifting is
 in getting buy-in across the organization that it is a worthwhile effort,
 getting control of your organization's mail flows and ensuring policies and
 procedures are communicated and followed. For complex environments there
 may need to be some automation required for creating and maintaining
 private/public key pairs and DNS records but that is much more
 straightforward than the aforementioned heavy lifting.

>>>
>>> Also note that said "heavy lifting" is not a one time expenditure of
>>> effort. Having hoisted the weight bar above your head, it requires
>>> organizational will and ongoing knowledge to stick to the higher bar week
>>> in and week out. Entropy is never your friend in an organizational security
>>> context. Neither are acquisitions :-)
>>>
>>> Yes, and that's why I use DMARC mostly as a tool for reporting. My
>>> clients are typically small businesses who are worried about selling
>>> widgets not about email so even if I help them set up email perfectly, they
>>> could make a change a year from now without updating their SPF record or
>>> deploying DKIM. I just changed my policy to reject (just for fun) assuming
>>> this email will get through because of DMARC's OR logic.
>>>
>>
> Which brings us back to the question of organizational implementation
> issues vs  interoperability issues. Can a technical standards body solve
> the problem of organizations shooting themselves in the foot because they
> are worried about selling widgits and not about email? Why do I have a
> feeling they start caring about email when it no longer works for them?
> They have created a self induced personal interoperability issue. If they
> changed their MX to use a random port other than port 25 to receive SMTP
> connections would you suggest that the RFC should be written to
> accommodate that?
>
> No, it probably can't solve that sort of problem and maybe there's not
really a problem. DMARC does work as advertised, though adoption's low.

 Under 50% of companies have any DMARC record. Of those who deploy DMARC,
about ~2% have p=quarantine and ~5% p=reject, though some industries such
as finance it looks like it's closer to 15% p=reject. I'm sure these
numbers aren't perfect but what you have likely isn't radically different.

Why is adoption low? Is that a big problem? Why so few aggressive policies?
Is that a big problem?

Can a standards body do anything about any of it? Should they? I have no
idea.
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] draft-crocker-dmarc-author-00 ?

[Jim Fenton]

On 8/14/20 11:30 AM, Kurt Andersen (b) wrote:
> On Fri, Aug 14, 2020 at 9:23 AM Dotzero  > wrote:
>
>
>  Is this an interoperability problem that is solved by IETF
> standards or is it an organizational problem that requires an
> organizational solution? Perhaps we need to generate an RFC
> entitled "Don't Do Stupid Things". ;-)
>
>
> I think that it might be out of the DMARC-WG's charter, but such an
> RFC would be eminently quotable along with 2549 and other such work.

We already have a number of such RFCs:

https://datatracker.ietf.org/doc/search?name=considered+harmful==on=on=group=

-Jim

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

Re: [dmarc-ietf] draft-crocker-dmarc-author-00 ?

[Kurt Andersen (b)]

On Fri, Aug 14, 2020 at 9:23 AM Dotzero  wrote:

>
>  Is this an interoperability problem that is solved by IETF standards or
> is it an organizational problem that requires an organizational solution?
> Perhaps we need to generate an RFC entitled "Don't Do Stupid Things". ;-)
>

I think that it might be out of the DMARC-WG's charter, but such an RFC
would be eminently quotable along with 2549 and other such work.

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

Re: [dmarc-ietf] draft-crocker-dmarc-author-00 ?

[Dotzero]

On Fri, Aug 14, 2020 at 1:32 PM Neil Anuskiewicz 
wrote:

>
>
> On Fri, Aug 14, 2020 at 8:13 AM Kurt Andersen (b) 
> wrote:
>
>> On Fri, Aug 14, 2020 at 7:31 AM Dotzero  wrote:
>>
>>>
>>> I've been involved in setting up DMARC with a policy of p=reject for
>>> somewhere North of 6,000 domains. As a sending domain, the heavy lifting is
>>> in getting buy-in across the organization that it is a worthwhile effort,
>>> getting control of your organization's mail flows and ensuring policies and
>>> procedures are communicated and followed. For complex environments there
>>> may need to be some automation required for creating and maintaining
>>> private/public key pairs and DNS records but that is much more
>>> straightforward than the aforementioned heavy lifting.
>>>
>>
>> Also note that said "heavy lifting" is not a one time expenditure of
>> effort. Having hoisted the weight bar above your head, it requires
>> organizational will and ongoing knowledge to stick to the higher bar week
>> in and week out. Entropy is never your friend in an organizational security
>> context. Neither are acquisitions :-)
>>
>> Yes, and that's why I use DMARC mostly as a tool for reporting. My
>> clients are typically small businesses who are worried about selling
>> widgets not about email so even if I help them set up email perfectly, they
>> could make a change a year from now without updating their SPF record or
>> deploying DKIM. I just changed my policy to reject (just for fun) assuming
>> this email will get through because of DMARC's OR logic.
>>
>
Which brings us back to the question of organizational implementation
issues vs  interoperability issues. Can a technical standards body solve
the problem of organizations shooting themselves in the foot because they
are worried about selling widgits and not about email? Why do I have a
feeling they start caring about email when it no longer works for them?
They have created a self induced personal interoperability issue. If they
changed their MX to use a random port other than port 25 to receive SMTP
connections would you suggest that the RFC should be written to
accommodate that?

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

Re: [dmarc-ietf] draft-crocker-dmarc-author-00 ?

[Neil Anuskiewicz]

On Fri, Aug 14, 2020 at 8:13 AM Kurt Andersen (b)  wrote:

> On Fri, Aug 14, 2020 at 7:31 AM Dotzero  wrote:
>
>>
>> I've been involved in setting up DMARC with a policy of p=reject for
>> somewhere North of 6,000 domains. As a sending domain, the heavy lifting is
>> in getting buy-in across the organization that it is a worthwhile effort,
>> getting control of your organization's mail flows and ensuring policies and
>> procedures are communicated and followed. For complex environments there
>> may need to be some automation required for creating and maintaining
>> private/public key pairs and DNS records but that is much more
>> straightforward than the aforementioned heavy lifting.
>>
>
> Also note that said "heavy lifting" is not a one time expenditure of
> effort. Having hoisted the weight bar above your head, it requires
> organizational will and ongoing knowledge to stick to the higher bar week
> in and week out. Entropy is never your friend in an organizational security
> context. Neither are acquisitions :-)
>
> Yes, and that's why I use DMARC mostly as a tool for reporting. My clients
> are typically small businesses who are worried about selling widgets not
> about email so even if I help them set up email perfectly, they could make
> a change a year from now without updating their SPF record or deploying
> DKIM. I just changed my policy to reject (just for fun) assuming this email
> will get through because of DMARC's OR logic.
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] draft-crocker-dmarc-author-00 ?

[Dotzero]

On Fri, Aug 14, 2020 at 11:13 AM Kurt Andersen (b)  wrote:

> On Fri, Aug 14, 2020 at 7:31 AM Dotzero  wrote:
>
>>
>> I've been involved in setting up DMARC with a policy of p=reject for
>> somewhere North of 6,000 domains. As a sending domain, the heavy lifting is
>> in getting buy-in across the organization that it is a worthwhile effort,
>> getting control of your organization's mail flows and ensuring policies and
>> procedures are communicated and followed. For complex environments there
>> may need to be some automation required for creating and maintaining
>> private/public key pairs and DNS records but that is much more
>> straightforward than the aforementioned heavy lifting.
>>
>
> Also note that said "heavy lifting" is not a one time expenditure of
> effort. Having hoisted the weight bar above your head, it requires
> organizational will and ongoing knowledge to stick to the higher bar week
> in and week out. Entropy is never your friend in an organizational security
> context. Neither are acquisitions :-)
>
> --Kurt
>

I absolutely agree with you, Kurt. On the other hand this is true for many
things. I almost want to respond with "What's your point?" (sarcastically).
Is this an interoperability problem that is solved by IETF standards or is
it an organizational problem that requires an organizational solution?
Perhaps we need to generate an RFC entitled "Don't Do Stupid Things". ;-)

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

Re: [dmarc-ietf] draft-crocker-dmarc-author-00 ?

[Kurt Andersen (b)]

On Fri, Aug 14, 2020 at 7:31 AM Dotzero  wrote:

>
> I've been involved in setting up DMARC with a policy of p=reject for
> somewhere North of 6,000 domains. As a sending domain, the heavy lifting is
> in getting buy-in across the organization that it is a worthwhile effort,
> getting control of your organization's mail flows and ensuring policies and
> procedures are communicated and followed. For complex environments there
> may need to be some automation required for creating and maintaining
> private/public key pairs and DNS records but that is much more
> straightforward than the aforementioned heavy lifting.
>

Also note that said "heavy lifting" is not a one time expenditure of
effort. Having hoisted the weight bar above your head, it requires
organizational will and ongoing knowledge to stick to the higher bar week
in and week out. Entropy is never your friend in an organizational security
context. Neither are acquisitions :-)

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

Re: [dmarc-ietf] draft-crocker-dmarc-author-00 ?

[Dotzero]

On Thu, Aug 13, 2020 at 6:53 PM Neil Anuskiewicz 
wrote:

>
>
> On Thu, Aug 13, 2020 at 2:33 PM Doug Foster  40bayviewphysicians@dmarc.ietf.org> wrote:
>
>> If I followed Neil’s discussion of MajorCRM:
>>
>>
>>
>> The current DMARC architecture supports authorizing a vendor to mail on
>> behalf of their clients if the client includes them in their SPF policy or
>> delegates a DKIM scope to them and they use it.
>>
>
> And client's domain is only in the Mail from uses the vendor's domain (
> somevendorxyz123.foo.com). It passes SPF in but it's not in alignment
> with the organizational domain name (example.com) that the client uses in
> the header from.
>
> This is super common and, as a practical matter, it works... except if you
> ever want to use DMARC's policy for anything other than reporting. The vast
> majority of people think that if you add include:bar.com (whatever vendor
> KB says) in the SPF that they are good to go.
>

"Vast majority of people"? Can you please provide data that supports this
assertion?


> So many businesses have several entries in their organizational domain's
> SPF record yet the RFC5321.from is the vendor's domain. The client
> sometimes goes over the 10 DNS lookups with includes that aren't doing
> anything for them. I'm not sure that 10 DNS lookup limit. There are some
> prominent services of various sorts for which the single include will do
> over 10 DNS lookups and hat's just one of many includes a client might have
> (I know this isn't about SPF per se).
>
> Yes, I can usually quickly set up a subdomain to use instead of
> somevendorxyz123.foo.com but this isn't always possible or it requires
> pushing to get it done.
>

So you are saying "Email authentication is hard. Let's go shopping"?

>
> This makes DMARC a sketchy tool to use for any policy above none which is
> in and of itself useful.
>

Not at all. It simply means that the people/organizations involved have
some problems. Please consider the following joke:

How many Psychiatrists does it take to change a light bulb? Only one but
the bulb has to want to change.

I've been involved in setting up DMARC with a policy of p=reject for
somewhere North of 6,000 domains. As a sending domain, the heavy lifting is
in getting buy-in across the organization that it is a worthwhile effort,
getting control of your organization's mail flows and ensuring policies and
procedures are communicated and followed. For complex environments there
may need to be some automation required for creating and maintaining
private/public key pairs and DNS records but that is much more
straightforward than the aforementioned heavy lifting.

Michael Hammer.

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

Re: [dmarc-ietf] draft-crocker-dmarc-author-00 ?

[Dotzero]

On Thu, Aug 13, 2020 at 5:43 PM Kurt Andersen (b)  wrote:

> On Thu, Aug 13, 2020 at 2:33 PM Doug Foster  40bayviewphysicians@dmarc.ietf.org> wrote:
>
>> The current DMARC architecture supports authorizing a vendor to mail on
>> behalf of their clients if the client includes them in their SPF policy or
>> delegates a DKIM scope to them and they use it.
>>
>>
>>
>> I agree that SPF is too limiting (including hard limits on complexity),
>> and DKIM is too complex for an uncooperative vendor.
>>
>>
>>
>> In most cases, a solution would be a controlled third-party signature
>> authorization along the lines of RFC 6541.
>>
>> The client would configure the authorization in his own DNS and the and
>> the vendor would only need to sign with their own DKIM signature.
>>
>
> If "DKIM is too complex for [this] uncooperative vendor", why would having
> the "vendor...sign with...DKIM" be workable?
>

Wrong answer. If the vendor is uncooperative then fire the vendor. 4-5
years ago it was difficult to find vendors who were willing to deal with
DKIM and able to do a good job in implementing. The common mantra was "how
does this fit into my business model". These days I would consider it table
stakes.

Michael Hammer

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

Re: [dmarc-ietf] draft-crocker-dmarc-author-00 ?

[Kurt Andersen (b)]

On Thu, Aug 13, 2020 at 2:33 PM Doug Foster  wrote:

> The current DMARC architecture supports authorizing a vendor to mail on
> behalf of their clients if the client includes them in their SPF policy or
> delegates a DKIM scope to them and they use it.
>
>
>
> I agree that SPF is too limiting (including hard limits on complexity),
> and DKIM is too complex for an uncooperative vendor.
>
>
>
> In most cases, a solution would be a controlled third-party signature
> authorization along the lines of RFC 6541.
>
> The client would configure the authorization in his own DNS and the and
> the vendor would only need to sign with their own DKIM signature.
>

If "DKIM is too complex for [this] uncooperative vendor", why would having
the "vendor...sign with...DKIM" be workable?

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

Re: [dmarc-ietf] draft-crocker-dmarc-author-00 ?

[Kurt Andersen (b)]

On Thu, Aug 13, 2020 at 12:06 PM Neil Anuskiewicz 
wrote:

>
> Tunable! You said the magic word I have a client now getting spoofing.
>

Receiving spoofed mail or having their domain *being* spoofed?


> My point is that it sure would be nice to be able to tune so that BigCRM
> and BigCRM Marketing * mail would pass DMARC comfortably, and we could then
> turn the dial on policy to cut off the spoofers without breaking legit mail.
>

Passing DMARC is not a be-all-end-all. That's what local policy is for. I
fail to see why local policy would not solve your problem (as described).

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

Re: [dmarc-ietf] draft-crocker-dmarc-author-00 ?

[Doug Foster]

If I followed Neil’s discussion of MajorCRM:

 

The current DMARC architecture supports authorizing a vendor to mail on behalf 
of their clients if the client includes them in their SPF policy or delegates a 
DKIM scope to them and they use it.

 

I agree that SPF is too limiting (including hard limits on complexity), and 
DKIM is too complex for an uncooperative vendor.

 

In most cases, a solution would be a controlled third-party signature 
authorization along the lines of RFC 6541.

The client would configure the authorization in his own DNS and the and the 
vendor would only need to sign with their own DKIM signature.   This is not an 
unreasonable ask for most vendors, but this particular one seems inexcusable.

 

Unfortunately, the past attempts with third-party signatures have died for lack 
of interest.  The clients of this vendor might be motivated to participate, but 
it would also require participation from the domains that receive messages from 
this vendor on behalf of the client.   Dave Crocker’s proposal has the same 
obstacles because it is a form of third-party signature authorization.

 

We would need to find a highly respected mailer who thinks they could stir up 
interest from their clients.   But major mailers will not depend on a new 
system until they are sure that it is fully deployed.   So the chicken-and-egg 
problem may doom every effort.

 

DF

 

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

Re: [dmarc-ietf] draft-crocker-dmarc-author-00 ?

[Neil Anuskiewicz]

On Thu, Aug 13, 2020 at 12:21 PM Dotzero  wrote:

>
>
> On Thu, Aug 13, 2020 at 3:06 PM Neil Anuskiewicz 
> wrote:
>
>>
>>
>> Tunable! You said the magic word I have a client now getting spoofing.
>> Tightening above p=none is a non starter as about 100% of MajorCRM emails
>> fail SPF (foo.majorcrm is the RFC5321.from), 62% of MajorCRM mail fails
>> DKIM, and 100% of MajorCRM Marketing * fails SPF (bar.some-esp.com). Oh,
>> and some local office has a random MailChimp account not authenticated.
>>
>> We can't turn the knob on policy and MajorCRM support says you can't have
>> your own mail from. Normally, with a client we would get on a screen share
>> with Bob (the doer of all things) at a company or some other efficient
>> arrangment to be able to make changes in applications, update DNS, test,
>> monitor.
>>
>> Here, there's this dept with control of the CRM, another for marketing,
>> another controls DNS, and a vendor says something isn't possible.
>>
>> So what you are saying is that you want an IETF working group to write a
> standard that papers over poor self control on the part of your
> organization.
>

Not my organization. I'm a freelancer. No, I'm saying that the IETF should
write a standard that helps people in the field solve problems.

>
>
>> My point is that it sure would be nice to be able to tune so that BigCRM
>> and BigCRM Marketing * mail would pass DMARC comfortably, and we could then
>> turn the dial on policy to cut off the spoofers without breaking legit mail.
>>
>> Yes, I know that this isn't the mailing list issue but tuning could solve
>> that problem, too.
>>
>>
> The way you solve the problem described above is to get control of your
> mail flows. I've worked with various "big CRM" vendors and they will gladly
> accept a delegated subdomain (they control DNS and therefore SPF and DKIM
> signing as well as publishing DMARC. There are other approaches as well.
> Your post illustrates one of the problems with the discussion on this list.
> People are conflating internal organizational issues with requirements for
> interoperability. You could always publish 0.0.0.0 -all for your SPF record
> and solve all your DMARC assertion issues very easily.
>

I set up subdomains for clients to use for their mail streams all the time
so I agree. It's just the standard that sometimes stands in the way of
cutting off spoofers. And that's ultimately the goal of the standard. Allow
legit mail, stop bad guys.
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] draft-crocker-dmarc-author-00 ?

[Dotzero]

On Thu, Aug 13, 2020 at 3:06 PM Neil Anuskiewicz 
wrote:

>
>
> Tunable! You said the magic word I have a client now getting spoofing.
> Tightening above p=none is a non starter as about 100% of MajorCRM emails
> fail SPF (foo.majorcrm is the RFC5321.from), 62% of MajorCRM mail fails
> DKIM, and 100% of MajorCRM Marketing * fails SPF (bar.some-esp.com). Oh,
> and some local office has a random MailChimp account not authenticated.
>
> We can't turn the knob on policy and MajorCRM support says you can't have
> your own mail from. Normally, with a client we would get on a screen share
> with Bob (the doer of all things) at a company or some other efficient
> arrangment to be able to make changes in applications, update DNS, test,
> monitor.
>
> Here, there's this dept with control of the CRM, another for marketing,
> another controls DNS, and a vendor says something isn't possible.
>
> So what you are saying is that you want an IETF working group to write a
standard that papers over poor self control on the part of your
organization.


> My point is that it sure would be nice to be able to tune so that BigCRM
> and BigCRM Marketing * mail would pass DMARC comfortably, and we could then
> turn the dial on policy to cut off the spoofers without breaking legit mail.
>
> Yes, I know that this isn't the mailing list issue but tuning could solve
> that problem, too.
>
>
The way you solve the problem described above is to get control of your
mail flows. I've worked with various "big CRM" vendors and they will gladly
accept a delegated subdomain (they control DNS and therefore SPF and DKIM
signing as well as publishing DMARC. There are other approaches as well.
Your post illustrates one of the problems with the discussion on this list.
People are conflating internal organizational issues with requirements for
interoperability. You could always publish 0.0.0.0 -all for your SPF record
and solve all your DMARC assertion issues very easily.

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

Re: [dmarc-ietf] draft-crocker-dmarc-author-00 ?

[Neil Anuskiewicz]

On Thu, Aug 13, 2020 at 1:57 AM Alessandro Vesely  wrote:

> On 2020-08-12 5:16 p.m., Steve Atkins wrote:
> > On 12/08/2020 04:32, Dave Crocker wrote:
> >>
> >> Here's why I think it won't:  They already have From:.
> >>
> >> The real value in DMARC is not what is displayed to the end-user but
> >> in having a required field that cites the originating domain name.
> >> That doesn't change if there are additional fields that might or
> >> might not mention the originating domain.
> >
> > I think we disagree on the goal of DMARC. The entire point of DMARC is
> > brand protection. Control over what is displayed to the user, not
> > what's in any particular header. You could use it for other things,
> > but that's what informed publishers of DMARC say they're using it for
> > (sometimes phrased as "protection against phishing" but that too is
> > all about what's displayed to the recipient).
>
>
> Both MX filtering and MUA displaying are relevant, possibly more or
> less relevant according to users and organizations.
>
>
> > If you display the contents of Author to the user, then DMARC
> > publishers will want to control that.
> >
> > If MUAs will display the contents of the Author: header where the
> > From: header is now then draft-crocker-dmarc-author-00 effectively
> > moves what used to be Sender: header to the From: header and what used
> > to be the From: header to the Author: header.
>
>
> I'd bet we have a good deal of time before MUAs react to the addition
> of Author:.  MX filters will react before them.  MLM software will
> hopefully react even faster.  In fact, MUAs reaction will be based
> rather on how the field usage will have been shaped by MXes and MLMs
> than on Dave's I-D directly.
>
> IMHO, Author: is a necessary complement to DKIM transformations.  One
> transformation being "From: was rewritten, original value was saved in
> Author:".  Based on that tag, a DKIM verifier can produce a
> canonicalization where the value of From: is put back in place, along
> with undoing other transformations, so as to verify the original
> signature.
>
>
> > You could achieve exactly the same result, with much less deployment
> > effort, by updating DMARC to enforce the Sender header and leaving
> > MUAs displaying the From: header.
>
>
> Sender: and Author: are not mutually exclusive.  While it's true that
> they aim at the same result, they are /not exactly/ like each other.
> MLMs already set Sender:, and can easily begin to set Author:, but
> won't stop to rewrite From: until they know MXes have upgraded.  We
> should conceive a standard that allows such dynamics.
>
>
> > That wouldn't be acceptable to anyone who wants to publish DMARC,
> > so the Author: proposal won't be either.
>
> Both these workarounds presume that domains hosting users' mailboxes
> may want to publish a somewhat relaxed policy, yet stricter than
> p=none.  That seems plausible, especially if the class of acceptable
> senders is tunable.


Tunable! You said the magic word I have a client now getting spoofing.
Tightening above p=none is a non starter as about 100% of MajorCRM emails
fail SPF (foo.majorcrm is the RFC5321.from), 62% of MajorCRM mail fails
DKIM, and 100% of MajorCRM Marketing * fails SPF (bar.some-esp.com). Oh,
and some local office has a random MailChimp account not authenticated.

We can't turn the knob on policy and MajorCRM support says you can't have
your own mail from. Normally, with a client we would get on a screen share
with Bob (the doer of all things) at a company or some other efficient
arrangment to be able to make changes in applications, update DNS, test,
monitor.

Here, there's this dept with control of the CRM, another for marketing,
another controls DNS, and a vendor says something isn't possible.

My point is that it sure would be nice to be able to tune so that BigCRM
and BigCRM Marketing * mail would pass DMARC comfortably, and we could then
turn the dial on policy to cut off the spoofers without breaking legit mail.

Yes, I know that this isn't the mailing list issue but tuning could solve
that problem, too.

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

Re: [dmarc-ietf] draft-crocker-dmarc-author-00 ?

[Alessandro Vesely]

On 2020-08-12 5:16 p.m., Steve Atkins wrote:

On 12/08/2020 04:32, Dave Crocker wrote:


Here's why I think it won't:  They already have From:.

The real value in DMARC is not what is displayed to the end-user but 
in having a required field that cites the originating domain name. 
That doesn't change if there are additional fields that might or 
might not mention the originating domain.


I think we disagree on the goal of DMARC. The entire point of DMARC is 
brand protection. Control over what is displayed to the user, not 
what's in any particular header. You could use it for other things, 
but that's what informed publishers of DMARC say they're using it for 
(sometimes phrased as "protection against phishing" but that too is 
all about what's displayed to the recipient).



Both MX filtering and MUA displaying are relevant, possibly more or 
less relevant according to users and organizations.



If you display the contents of Author to the user, then DMARC 
publishers will want to control that.


If MUAs will display the contents of the Author: header where the 
From: header is now then draft-crocker-dmarc-author-00 effectively 
moves what used to be Sender: header to the From: header and what used 
to be the From: header to the Author: header.



I'd bet we have a good deal of time before MUAs react to the addition 
of Author:.  MX filters will react before them.  MLM software will 
hopefully react even faster.  In fact, MUAs reaction will be based 
rather on how the field usage will have been shaped by MXes and MLMs 
than on Dave's I-D directly.


IMHO, Author: is a necessary complement to DKIM transformations.  One 
transformation being "From: was rewritten, original value was saved in 
Author:".  Based on that tag, a DKIM verifier can produce a 
canonicalization where the value of From: is put back in place, along 
with undoing other transformations, so as to verify the original 
signature.



You could achieve exactly the same result, with much less deployment 
effort, by updating DMARC to enforce the Sender header and leaving 
MUAs displaying the From: header.



Sender: and Author: are not mutually exclusive.  While it's true that 
they aim at the same result, they are /not exactly/ like each other. 
MLMs already set Sender:, and can easily begin to set Author:, but 
won't stop to rewrite From: until they know MXes have upgraded.  We 
should conceive a standard that allows such dynamics.




That wouldn't be acceptable to anyone who wants to publish DMARC,
so the Author: proposal won't be either.


Both these workarounds presume that domains hosting users' mailboxes 
may want to publish a somewhat relaxed policy, yet stricter than 
p=none.  That seems plausible, especially if the class of acceptable 
senders is tunable.



Best
Ale
--






















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

Re: [dmarc-ietf] draft-crocker-dmarc-author-00 ?

[John Levine]

In article <0c8afc68-bc51-702a-c794-610b2d355...@dcrocker.net> you write:
>Here's why I think it won't:  They already have From:.

I was going to answer but Steve Atkins said it better.

Let's work on your Sender draft which doesn't try to change what MUAs display.

R's,
John

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

Re: [dmarc-ietf] draft-crocker-dmarc-author-00 ?

[Steve Atkins]

On 12/08/2020 04:32, Dave Crocker wrote:


Here's why I think it won't:  They already have From:.

The real value in DMARC is not what is displayed to the end-user but 
in having a required field that cites the originating domain name.  
That doesn't change if there are additional fields that might or might 
not mention the originating domain.


I think we disagree on the goal of DMARC. The entire point of DMARC is 
brand protection. Control over what is displayed to the user, not what's 
in any particular header. You could use it for other things, but that's 
what informed publishers of DMARC say they're using it for (sometimes 
phrased as "protection against phishing" but that too is all about 
what's displayed to the recipient).


If you display the contents of Author to the user, then DMARC publishers 
will want to control that.


If MUAs will display the contents of the Author: header where the From: 
header is now then draft-crocker-dmarc-author-00 effectively moves what 
used to be Sender: header to the From: header and what used to be the 
From: header to the Author: header.


You could achieve exactly the same result, with much less deployment 
effort, by updating DMARC to enforce the Sender header and leaving MUAs 
displaying the From: header. That wouldn't be acceptable to anyone who 
wants to publish DMARC, so the Author: proposal won't be either.


Cheers,
  Steve

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

Re: [dmarc-ietf] draft-crocker-dmarc-author-00 ?

[Neil Anuskiewicz]

On Wed, Aug 12, 2020 at 6:32 AM Dave Crocker  wrote:

> On 8/12/2020 6:23 AM, Neil Anuskiewicz wrote:
> > IETF are more relaxed than I expected.
>
> Don't believe it.  The advice was warranted.
>
> Well, it's good to mostly lurk for a while as a courtesy unless and until
I have something useful to contribute. I will say if there's help needed
with writing an FAQ, a RFP, or something else entirely that would be
useful, I'm willing to help.

My experience with DMARC has been hands-on implementation so thinking about
the protocol and how to make it better is new ground. I have idea if I'll
have any insight. I'll try to learn enough to contribute through lurking.


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

Re: [dmarc-ietf] draft-crocker-dmarc-author-00 ?

[Dave Crocker]

On 8/12/2020 6:23 AM, Neil Anuskiewicz wrote:

IETF are more relaxed than I expected.


Don't believe it.  The advice was warranted.

d/;

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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

Re: [dmarc-ietf] draft-crocker-dmarc-author-00 ?

[Neil Anuskiewicz]

On Wed, Aug 12, 2020 at 6:04 AM Dave Crocker  wrote:

> On 8/12/2020 5:55 AM, Neil Anuskiewicz wrote:
> >
> >
> > On Wed, Aug 12, 2020 at 5:13 AM Dave Crocker  > > wrote:
> >
> > On 8/12/2020 4:45 AM, Neil Anuskiewicz wrote:
> >  > Mr. Crocker, is there a document that describes some of these
> > proposals
> >  > and perhaps the best arguments for an against somewhere? The
> > firehose of
> >  > learning would a bit easier if there were a FAQ. I think it might
> > even
> >  > help the participants if this was all documented. Yes, I know
> > there's
> >  > the archived but I mean an organized and linear doc.
> >
> >
> >
> > If you have particular questions, ask them.
> >
> >
> > I've just recently started lurking but I think this is a discussion
> > about semantics. What to call a proposed RFC5322.Sender field.
>
> The reference to field name was for an alternative to the rfc5322.From
> field, not sender.
>
>
> > The problem being addressed is the munging of headers by mailing lists
> > and other forwarders, breaking things like DKIM.
>
> mailing lists pretty much always break DKIM.  One of the proposals is to
> try to recover signature validation, post hoc.
>
> > I've not been lurking long enough to grok what's going on but I'll
> > continue to lurk and learn, eventually finding a small way to contribute
> > to this effort even if it's just to sweep out the IETF Ashram. :-)
>
>
> Welcome aboard.
>
> Thank you. That was a warm welcome. The guy who recommended this list to
me suggested I lurk for like a year or get eaten alive. IETF are more
relaxed than I expected.


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

Re: [dmarc-ietf] draft-crocker-dmarc-author-00 ?

[Neil Anuskiewicz]

On Wed, Aug 12, 2020 at 6:04 AM Dave Crocker  wrote:

> On 8/12/2020 5:55 AM, Neil Anuskiewicz wrote:
> >
> >
> > On Wed, Aug 12, 2020 at 5:13 AM Dave Crocker  > > wrote:
> >
> > On 8/12/2020 4:45 AM, Neil Anuskiewicz wrote:
> >  > Mr. Crocker, is there a document that describes some of these
> > proposals
> >  > and perhaps the best arguments for an against somewhere? The
> > firehose of
> >  > learning would a bit easier if there were a FAQ. I think it might
> > even
> >  > help the participants if this was all documented. Yes, I know
> > there's
> >  > the archived but I mean an organized and linear doc.
> >
> >
> >
> > If you have particular questions, ask them.
> >
> >
> > I've just recently started lurking but I think this is a discussion
> > about semantics. What to call a proposed RFC5322.Sender field.
>
> The reference to field name was for an alternative to the rfc5322.From
> field, not sender.
>
> Ah, an alternative way for DMARC to come into alignment: RFC5322.Sender
== RFC5322.From so if tag is present permitting this alternative means of
alignment. With the tag present, the receiving system checks the DNS
of the RFC5322.Sender
domain. If the tag isn't present, it's business as usual.

My opinion is that having more ways to come into alignment available's a
good thing. I work mostly with small businesses that don't have zillions of
mail streams and moving parts. But DMARC sometimes finds rogue senders
within the organization (The Toledo office decided to do their own
marketing or Bob in sales is gonna make everything happen), legit senders
who aren't authenticated, mail streams everyone forgot about, and,
occasionally spoofers.

Even with a small business, turning the policy knob above none is
unnerving, especially if there's less than perfecto authentication across
the board on legit sources. I rarely go above none anyway but I do like the
option.



> > The problem being addressed is the munging of headers by mailing lists
> > and other forwarders, breaking things like DKIM.
>
> mailing lists pretty much always break DKIM.  One of the proposals is to
> try to recover signature validation, post hoc.
>
> > I've not been lurking long enough to grok what's going on but I'll
> > continue to lurk and learn, eventually finding a small way to contribute
> > to this effort even if it's just to sweep out the IETF Ashram. :-)
>
>
> Welcome aboard.
>
> d/
>
>
> --
> Dave Crocker
> Brandenburg InternetWorking
> bbiw.net
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] draft-crocker-dmarc-author-00 ?

[Dave Crocker]

On 8/12/2020 5:55 AM, Neil Anuskiewicz wrote:



On Wed, Aug 12, 2020 at 5:13 AM Dave Crocker > wrote:


On 8/12/2020 4:45 AM, Neil Anuskiewicz wrote:
 > Mr. Crocker, is there a document that describes some of these
proposals
 > and perhaps the best arguments for an against somewhere? The
firehose of
 > learning would a bit easier if there were a FAQ. I think it might
even
 > help the participants if this was all documented. Yes, I know
there's
 > the archived but I mean an organized and linear doc.



If you have particular questions, ask them.


I've just recently started lurking but I think this is a discussion 
about semantics. What to call a proposed RFC5322.Sender field.


The reference to field name was for an alternative to the rfc5322.From 
field, not sender.



The problem being addressed is the munging of headers by mailing lists 
and other forwarders, breaking things like DKIM.


mailing lists pretty much always break DKIM.  One of the proposals is to 
try to recover signature validation, post hoc.


I've not been lurking long enough to grok what's going on but I'll 
continue to lurk and learn, eventually finding a small way to contribute 
to this effort even if it's just to sweep out the IETF Ashram. :-)



Welcome aboard.

d/


--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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

Re: [dmarc-ietf] draft-crocker-dmarc-author-00 ?

[Neil Anuskiewicz]

On Wed, Aug 12, 2020 at 5:13 AM Dave Crocker  wrote:

> On 8/12/2020 4:45 AM, Neil Anuskiewicz wrote:
> > Mr. Crocker, is there a document that describes some of these proposals
> > and perhaps the best arguments for an against somewhere? The firehose of
> > learning would a bit easier if there were a FAQ. I think it might even
> > help the participants if this was all documented. Yes, I know there's
> > the archived but I mean an organized and linear doc.
>
>
>
> If you have particular questions, ask them.
>

I've just recently started lurking but I think this is a discussion about
semantics. What to call a proposed RFC5322.Sender field.

The problem being addressed is the munging of headers by mailing lists and
other forwarders, breaking things like DKIM.

I've not been lurking long enough to grok what's going on but I'll continue
to lurk and learn, eventually finding a small way to contribute to this
effort even if it's just to sweep out the IETF Ashram. :-)

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

Re: [dmarc-ietf] draft-crocker-dmarc-author-00 ?

[Dave Crocker]

On 8/12/2020 4:45 AM, Neil Anuskiewicz wrote:
Mr. Crocker, is there a document that describes some of these proposals 
and perhaps the best arguments for an against somewhere? The firehose of 
learning would a bit easier if there were a FAQ. I think it might even 
help the participants if this was all documented. Yes, I know there's 
the archived but I mean an organized and linear doc.



There is a small number of Internet Drafts.  Each of them explains 
themselves, well or poorly.


This kind of work is early-stage development and requires participants 
to be actively engaged in that development.  FAQs, for example, come 
later, for wider consumption.


If you have particular questions, ask them.

d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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

Re: [dmarc-ietf] draft-crocker-dmarc-author-00 ?

[Neil Anuskiewicz]

Mr. Crocker, is there a document that describes some of these proposals and
perhaps the best arguments for an against somewhere? The firehose of
learning would a bit easier if there were a FAQ. I think it might even help
the participants if this was all documented. Yes, I know there's the
archived but I mean an organized and linear doc.

On Tue, Aug 11, 2020 at 8:32 PM Dave Crocker  wrote:

>
> >> I was quite surprised -- at the level of astonished -- to see the
> >> pushback on the Author header-field proposal, since it is such a simple
> >> and straightforward mechanism.
> >
> > The different bits in the message are simple enough.
> >
> > The problem is that it might as well be called Really-From, and then
>
> Your opening item is that you don't like the name of the field?
>
> In any event, I suggested "Author" because it is simple and accurate.
> Something like what you suggest - on the off-chance you are serious --
> offers distracting tone and baggage.
>
>
> > when enough systems do mutant DMARC to cause the same problems with
> > Really-From that we have with From,
>
> That's a premise with no foundation and arguably no validity.
>
> At the least, if you are going to use this as the substance of your
> concern, perhaps you could explain with some care why you are so certain
> this will happen.
>
> Here's why I think it won't:  They already have From:.
>
> The real value in DMARC is not what is displayed to the end-user but in
> having a required field that cites the originating domain name.  That
> doesn't change if there are additional fields that might or might not
> mention the originating domain.
>
>
> > the step after that is
> > Really-Really-From, so on ad nauseam. While that happens (or maybe
> > doesn't) we have no idea whether MUAs will display it or let you enter
>
> The question of whether any MUAs will implement this is the same concern
> for any proposal.  So on its own, that would mean we never do anything
> unless implementers and operators promise to use it.  Absent an IETF
> formal policy to that end...
>
>
> > it or automatically make it the same as From or maybe something else,
> > likely making it a disaster for interoperability.
> >
> > I think the DMARC sender draft is a lot more promising.
>
> It has it's own problems.
>
> There's no perfection here, since the task is retro-fitting work-arounds
> to an established mechanism that has been altered.  As I've noted,
> realistically, DMARC makes the From: field be the Sender: field.
>
> 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] draft-crocker-dmarc-author-00 ?

[Dave Crocker]

I was quite surprised -- at the level of astonished -- to see the
pushback on the Author header-field proposal, since it is such a simple
and straightforward mechanism.


The different bits in the message are simple enough.

The problem is that it might as well be called Really-From, and then


Your opening item is that you don't like the name of the field?

In any event, I suggested "Author" because it is simple and accurate. 
Something like what you suggest - on the off-chance you are serious -- 
offers distracting tone and baggage.




when enough systems do mutant DMARC to cause the same problems with
Really-From that we have with From, 


That's a premise with no foundation and arguably no validity.

At the least, if you are going to use this as the substance of your 
concern, perhaps you could explain with some care why you are so certain 
this will happen.


Here's why I think it won't:  They already have From:.

The real value in DMARC is not what is displayed to the end-user but in 
having a required field that cites the originating domain name.  That 
doesn't change if there are additional fields that might or might not 
mention the originating domain.




the step after that is
Really-Really-From, so on ad nauseam. While that happens (or maybe
doesn't) we have no idea whether MUAs will display it or let you enter


The question of whether any MUAs will implement this is the same concern 
for any proposal.  So on its own, that would mean we never do anything 
unless implementers and operators promise to use it.  Absent an IETF 
formal policy to that end...




it or automatically make it the same as From or maybe something else,
likely making it a disaster for interoperability.

I think the DMARC sender draft is a lot more promising.


It has it's own problems.

There's no perfection here, since the task is retro-fitting work-arounds 
to an established mechanism that has been altered.  As I've noted, 
realistically, DMARC makes the From: field be the Sender: field.


d/


--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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

Re: [dmarc-ietf] draft-crocker-dmarc-author-00 ?

[John Levine]

In article  you write:
>Folks,
>
>I was quite surprised -- at the level of astonished -- to see the 
>pushback on the Author header-field proposal, since it is such a simple 
>and straightforward mechanism.

The different bits in the message are simple enough.  

The problem is that it might as well be called Really-From, and then
when enough systems do mutant DMARC to cause the same problems with
Really-From that we have with From, the step after that is
Really-Really-From, so on ad nauseam. While that happens (or maybe
doesn't) we have no idea whether MUAs will display it or let you enter
it or automatically make it the same as From or maybe something else,
likely making it a disaster for interoperability.

I think the DMARC sender draft is a lot more promising.

R's,
John

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

Re: [dmarc-ietf] draft-crocker-dmarc-author-00

[Dave Crocker]

On 7/14/2020 6:48 AM, Hector Santos wrote:
It will modify all specs related to DKIM where there is an Author 
(5322.From) design requirement.



It does not need to affect DKIM at all.


d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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

Re: [dmarc-ietf] draft-crocker-dmarc-author-00

[Hector Santos]

On 7/13/2020 12:29 PM, Alessandro Vesely wrote:


I'd support making that a WG I-D.


I am having trouble with it, so ~1


IMHO, it could be standard track and modify RFC 5322 if accepted.


It will modify all specs related to DKIM where there is an Author 
(5322.From) design requirement.


I don't see how a new "5322.Author" header changes anything especially 
if NOT defined with the following characteristics:


- MUST NOT be modified
- MUST be hash to signature.

Dave, indicated it is expected to be hashed bound to the signature. 
That makes a SHOULD but not a MUST.


I don't see how we can trust a DKIM-signature that has no immutable 
identity requirement to it.


--
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] draft-crocker-dmarc-author-00

[Hector Santos]

On 7/13/2020 8:23 PM, Dave Crocker wrote:

On 7/13/2020 12:08 PM, Joseph Brennan wrote:

We already have a field for author, called From. Why add another one?


Simple summary:

  These days, the original From: field is tending to get corrupted
and we need some place to put author information that won't be.


Then imo, it must be an immutable header object and a requirement to 
be hash bound.  This changes DKIM-BASE and the DKIM Policy protocol. 
Lacking this requirement, leaves open a variety of loop-holes.



--
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] draft-crocker-dmarc-author-00

[Dave Crocker]

On 7/13/2020 12:08 PM, Joseph Brennan wrote:

We already have a field for author, called From. Why add another one?



1. Note that the From: field typically serves two different semantic 
roles, author and 'handling agent' (ie, Sender:)


2. Pars 3 &6 of the Introduction lay the foundation for needing a new 
and separate header field.


Simple summary:

 These days, the original From: field is tending to get corrupted 
and we need some place to put author information that won't be.



d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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

Re: [dmarc-ietf] draft-crocker-dmarc-author-00

[Joseph Brennan]

We already have a field for author, called From. Why add another one?

"The only required header fields are the origination date field and
the originator address field(s)." By this, RFC 5322 refers to the From
field. I think client software developers would be inclined to ignore
creating the Author field, or else to create it and populate it with
the same value as the From field. Mailing list software might want to
create Author and copy the value of From into it, and then insert the
list address into the From, but then, they run into "In all cases, the
"From:" field SHOULD NOT contain any mailbox that does not belong to
the author(s) of the message." No better than where we are now, is it?


-- 
Joseph Brennan
Lead, Email and Systems Applications

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

Re: [dmarc-ietf] draft-crocker-dmarc-author-00

[Dave Crocker]

On 7/13/2020 11:29 AM, Alessandro Vesely wrote:

IMHO, it could be standard track and modify RFC 5322 if accepted.
The mail header is extensible.  Addition of header fields does not 
require modifying the base specification.
Restricting From: to be single-address, or at least having all domain 
parts aligned to one another does require an updates= tag.



ahh.  hadn't seen that was your point.  well, whenever there is an 
effort to do substantial revisions to mail format, this might be worth 
considering.



d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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

Re: [dmarc-ietf] draft-crocker-dmarc-author-00

[Alessandro Vesely]

On 13/07/2020 19:27, Dave Crocker wrote:

On 7/13/2020 9:29 AM, Alessandro Vesely wrote:

On 13/07/2020 05:10, Dave Crocker wrote:

I've just submitted an initial draft to define an RFC5322.Author field:

https://datatracker.ietf.org/doc/draft-crocker-dmarc-author/



Dave,
since you also posted a second draft, I'd strike considerations about the 
Sender: from this one.  In particular, the 4th paragraph of the Introduction, 
"Because the current [...]", is distracting and unhelpful.


Unfortunately, misunderstanding of the relevant human factors is often 
introduced in discussions in this realm.  People are remarkably resistant to 
the behavioral facts on his, so, unfortunately, it needs repeating.



It'd be enough to say Sender: is syntactically and semantically different.


Another use case of Author: is to indicate multiple authors. 


That's supported by the draft spec, since it copied From: syntax.


I'd support making that a WG I-D. 


Thanks.



Thank you.



IMHO, it could be standard track and modify RFC 5322 if accepted.


The mail header is extensible.  Addition of header fields does not require 
modifying the base specification.



Restricting From: to be single-address, or at least having all domain parts 
aligned to one another does require an updates= tag.  Of course, ticket 74 has 
to be addressed in dmarc-bis too, or one of its parts, since Alexey said we are 
likely to split up the current document into multiple drafts.  If the Author: 
I-D is going to be one of those parts, it's be convenient to recap usage of 
Originator Fields in the DMARC era in a single, short document.



Best
Ale
--
























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

Re: [dmarc-ietf] draft-crocker-dmarc-author-00

[Dave Crocker]

On 7/13/2020 9:29 AM, Alessandro Vesely wrote:

On 13/07/2020 05:10, Dave Crocker wrote:

I've just submitted an initial draft to define an RFC5322.Author field:

https://datatracker.ietf.org/doc/draft-crocker-dmarc-author/



Dave,
since you also posted a second draft, I'd strike considerations about 
the Sender: from this one.  In particular, the 4th paragraph of the 
Introduction, "Because the current [...]", is distracting and unhelpful.


Unfortunately, misunderstanding of the relevant human factors is often 
introduced in discussions in this realm.  People are remarkably 
resistant to the behavioral facts on his, so, unfortunately, it needs 
repeating.



I'd explicitly mention DMARC, rather than use circumlocutions 
mentioning generic email protections which use the From: field.


I've learned to write specification for the long-term, notably trying to 
avoid ephemeral references that won't apply years later.  The proposal 
here stands on its own.  Motivated by DMARC issues, but I'd argue not 
dependent on it.



Another use case of Author: is to indicate multiple authors. 


That's supported by the draft spec, since it copied From: syntax.


I'd support making that a WG I-D. 


Thanks.



IMHO, it could be standard track and modify RFC 5322 if accepted.


The mail header is extensible.  Addition of header fields does not 
require modifying the base specification.


d/


--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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

Re: [dmarc-ietf] draft-crocker-dmarc-author-00

[Alessandro Vesely]

On 13/07/2020 05:10, Dave Crocker wrote:

I've just submitted an initial draft to define an RFC5322.Author field:

  https://datatracker.ietf.org/doc/draft-crocker-dmarc-author/



Dave,
since you also posted a second draft, I'd strike considerations about the 
Sender: from this one.  In particular, the 4th paragraph of the Introduction, 
"Because the current [...]", is distracting and unhelpful.


I'd explicitly mention DMARC, rather than use circumlocutions mentioning 
generic email protections which use the From: field.


Another use case of Author: is to indicate multiple authors.  Like From: and 
unlike Sender:, Author: supports a list of mailboxes.  Since, DMARC filters 
don't behave well with multi-address From:, using Author: can be a handy 
alternative for those joint messages.  In fact, the current spec says:


   o  Messages bearing a single RFC5322.From field containing multiple
  addresses (and, thus, multiple domain names to be evaluated) are
  typically rejected because the sorts of mail normally protected by
  DMARC do not use this format;

I submitted ticket 74[*] to address the latter point, which is inconsistent as 
either all or none of the mail belonging to a given domain is subject to DMARC 
filtering.  There is no way to define which sorts of mail is "normally 
protected".  The quoted rule deviously restricts the format of From:.


I'd support making that a WG I-D.  IMHO, it could be standard track and modify 
RFC 5322 if accepted.



Best
Ale
--

[*] https://trac.ietf.org/trac/dmarc/ticket/74

































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