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

From: Dave Crocker <[email-masked]>
Date: Mon, 10 Aug 2020 12:10:30 -0700

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.

I'd like to ask for clarity from the group on both concerns about it and 
desires for it.

d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: "John Levine" <[email-masked]>
Date: 10 Aug 2020 23:47:40 -0400

>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

---

From: Dave Crocker <[email-masked]>
Date: Tue, 11 Aug 2020 20:32:23 -0700

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

> 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

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

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

---

From: Neil Anuskiewicz <[email-masked]>
Date: Wed, 12 Aug 2020 04:45:16 -0700

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 <[email-masked]> wrote:

> _______________________________________________
> dmarc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmarc
>

---

From: Dave Crocker <[email-masked]>
Date: Wed, 12 Aug 2020 05:13:09 -0700

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/

---

From: Neil Anuskiewicz <[email-masked]>
Date: Wed, 12 Aug 2020 05:55:03 -0700

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

---

From: Dave Crocker <[email-masked]>
Date: Wed, 12 Aug 2020 06:03:59 -0700

On 8/12/2020 5:55 AM, Neil Anuskiewicz wrote:
> 
> 
> On Wed, Aug 12, 2020 at 5:13 AM Dave Crocker <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
> 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/

---

From: Neil Anuskiewicz <[email-masked]>
Date: Wed, 12 Aug 2020 06:22:30 -0700

On Wed, Aug 12, 2020 at 6:04 AM Dave Crocker <[email-masked]> wrote:

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

---

From: Neil Anuskiewicz <[email-masked]>
Date: Wed, 12 Aug 2020 06:23:55 -0700

On Wed, Aug 12, 2020 at 6:04 AM Dave Crocker <[email-masked]> wrote:

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

---

From: Dave Crocker <[email-masked]>
Date: Wed, 12 Aug 2020 06:32:34 -0700

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/;

---

From: Neil Anuskiewicz <[email-masked]>
Date: Wed, 12 Aug 2020 07:02:59 -0700

On Wed, Aug 12, 2020 at 6:32 AM Dave Crocker <[email-masked]> wrote:

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

---

From: Steve Atkins <[email-masked]>
Date: Wed, 12 Aug 2020 16:16:39 +0100

On 12/08/2020 04:32, Dave Crocker wrote:
> 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

---

From: "John Levine" <[email-masked]>
Date: 12 Aug 2020 16:09:07 -0400

>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

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 13 Aug 2020 10:57:11 +0200

On 2020-08-12 5:16 p.m., Steve Atkins wrote:
>> That doesn't change if there are additional fields that might or 
>> might not mention the originating domain.
> 
> 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.

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

---

From: Neil Anuskiewicz <[email-masked]>
Date: Thu, 13 Aug 2020 12:06:02 -0700

> p=none.  That seems plausible, especially if the class of acceptable

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

---

From: Dotzero <[email-masked]>
Date: Thu, 13 Aug 2020 15:20:46 -0400

On Thu, Aug 13, 2020 at 3:06 PM Neil Anuskiewicz <[email-masked]>
wrote:

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

> Yes, I know that this isn't the mailing list issue but tuning could solve
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

---

From: Neil Anuskiewicz <[email-masked]>
Date: Thu, 13 Aug 2020 12:41:50 -0700

> standard that papers over poor self control on the part of your

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.

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

---

From: "Doug Foster" <[email-masked]>
Date: Thu, 13 Aug 2020 17:32:41 -0400

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

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Thu, 13 Aug 2020 14:38:40 -0700

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

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

> 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

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Thu, 13 Aug 2020 14:42:22 -0700

On Thu, Aug 13, 2020 at 2:33 PM Doug Foster <fosterd=
[email-masked]> 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

---

From: Dotzero <[email-masked]>
Date: Thu, 13 Aug 2020 17:53:30 -0400

> 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

---

From: Neil Anuskiewicz <[email-masked]>
Date: Thu, 13 Aug 2020 15:52:50 -0700

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

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

---

From: Dotzero <[email-masked]>
Date: Fri, 14 Aug 2020 10:31:35 -0400

On Thu, Aug 13, 2020 at 6:53 PM Neil Anuskiewicz <[email-masked]>
wrote:

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

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

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.

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Fri, 14 Aug 2020 08:12:32 -0700

> 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

---

From: Dotzero <[email-masked]>
Date: Fri, 14 Aug 2020 12:23:13 -0400

> context. Neither are acquisitions :-)

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

---

From: Neil Anuskiewicz <[email-masked]>
Date: Fri, 14 Aug 2020 10:32:04 -0700

On Fri, Aug 14, 2020 at 8:13 AM Kurt Andersen (b) <[email-masked]> wrote:

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

---

From: Dotzero <[email-masked]>
Date: Fri, 14 Aug 2020 14:15:39 -0400

On Fri, Aug 14, 2020 at 1:32 PM Neil Anuskiewicz <[email-masked]>
wrote:

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

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Fri, 14 Aug 2020 11:30:35 -0700

On Fri, Aug 14, 2020 at 9:23 AM Dotzero <[email-masked]> wrote:

>
>  Is this an interoperability problem that is solved by IETF standards or
> is it an organizational problem that requires an organizational solution?

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

---

From: Jim Fenton <[email-masked]>
Date: Fri, 14 Aug 2020 12:15:54 -0700

On 8/14/20 11:30 AM, Kurt Andersen (b) wrote:
> On Fri, Aug 14, 2020 at 9:23 AM Dotzero <[email-masked]
> <mailto:[email-masked]>> 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&sort=&rfcs=on&activedrafts=on&by=group&group=

-Jim

---

From: Neil Anuskiewicz <[email-masked]>
Date: Fri, 14 Aug 2020 12:47:09 -0700

On Fri, Aug 14, 2020 at 11:15 AM Dotzero <[email-masked]> wrote:

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

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Fri, 14 Aug 2020 13:41:56 -0700

> https://datatracker.ietf.org/doc/search?name=considered+harmful&sort=&rfcs=on&activedrafts=on&by=group&group=
Maybe we should write _Implementing Email Security Without Understanding
What You Are Doing Is Considered Harmful_ - that could fall within our
remit.

--Kurt

---

From: Dave Crocker <[email-masked]>
Date: Sat, 15 Aug 2020 10:37:13 -0700

Steve, et al,

On 8/12/2020 8:16 AM, Steve Atkins wrote:
> 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.

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

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

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

---

From: Dave Crocker <[email-masked]>
Date: Sat, 15 Aug 2020 10:51:50 -0700

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/

---

From: Dave Crocker <[email-masked]>
Date: Sat, 15 Aug 2020 10:57:42 -0700

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

---

From: "John Levine" <[email-masked]>
Date: 15 Aug 2020 15:48:47 -0400

>Also, I'm sorry to hear that the wg isn't capable of discussing two 

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

---

From: Dave Crocker <[email-masked]>
Date: Sat, 15 Aug 2020 13:35:39 -0700

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

---

From: "John R Levine" <[email-masked]>
Date: 15 Aug 2020 18:59:39 -0400

On Sat, 15 Aug 2020, Dave Crocker wrote:
>> I'm pretty sure that my opinions about -author and -sender would be the 
>> same even if they'd been published a year apart.
>
> 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, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Dave Crocker <[email-masked]>
Date: Sat, 15 Aug 2020 16:02:09 -0700

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

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

d/

---

From: "Luis E. Muñoz" <[email-masked]>
Date: Mon, 17 Aug 2020 13:00:06 -0700

> numbers aren't perfect but what you have likely isn't radically 

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 

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

---

From: "John Levine" <[email-masked]>
Date: 17 Aug 2020 16:16:39 -0400

In article <[email-masked]> you write:
>> Why is adoption low? Is that a big problem? Why so few aggressive 
>> policies? Is that a big problem?
>

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.

---

From: Neil Anuskiewicz <[email-masked]>
Date: Tue, 18 Aug 2020 10:32:23 -0700

On Mon, Aug 17, 2020 at 1:00 PM Luis E. Muñoz <dmarc-ietf.org=
[email-masked]> wrote:

> 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

---

From: Jesse Thompson <[email-masked]>
Date: Tue, 18 Aug 2020 14:34:14 -0500

On 8/13/20 4:53 PM, [email-masked] wrote:
> 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.

DKIM, DMARC policy conformance, or any practical email functionality are rarely considered in procurement decisions.  Only recently did I manage to get some of these requirements into our organization's RFP templates.  It really hasn't made any impact on procurement decisions, which are made by people who don't understand the nuances of email to the extend that they can tell if the vendor actually meets the requirements.  Even if I were included on the evaluation team for every procurement (a job I do not want) it would be rare that lack of DKIM support would be enough to weigh negatively on a decision.

People like me only get called in after the system is deployed in production and they run into problems getting email delivered.  For one recently-procured (inventory management software) vendor, I had to coach a poor sysadmin through how to set up Postfix to relay-rewrite their own application's email so that it wasn't able to outright spoof (for lack of a better term) the address of any end-user-free-hand-inputted address.  Their own app dev team didn't feel like it was important enough to learn about DKIM/SPF/DMARC and kept confusing the changes they needed to make for email authentication with TLS 1.0 deprecation.  "It's in our next release" they kept saying.  

Companies like that will just check the "we support DMARC" on the procurement form because they don't know enough to understand that they don't.

Jesse

---

From: Jesse Thompson <[email-masked]>
Date: Tue, 18 Aug 2020 14:42:30 -0500

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