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

From: Tim Wicinski <[email-masked]>
Date: Mon, 10 Aug 2020 15:04:46 -0400

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

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

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

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

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

Please also indicate if you are willing to contribute text, review, etc.

This call for adoption ends: 24 August 2020

Thanks,
tim wicinski

---

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

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

+1 for adopting the document into the WG for continued discussion.

--Kurt

---

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

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

+1, the I-D needs work and coordination with other I-Ds by the WG.

> Please also indicate if you are willing to contribute text, review, etc.

Yes, I will.

Best
Ale
--

---

From: "John Levine" <[email-masked]>
Date: 13 Aug 2020 19:12:31 -0400

In article <[email-masked]> you write:
>-=-=-=-=-=-

It needs some work but it's worth adopting.

I might do a review or two but you know how shy I am.

R's,
John

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 13 Aug 2020 17:23:07 -0700

On Mon, Aug 10, 2020 at 12:05 PM Tim Wicinski <[email-masked]> wrote:

> to see adoption of this work, this can be changed back to "Standards
> Track" before

DISCUSS.

(just kidding; +1 for adoption)

-MSK, participating, except for the joke part, that was with full authority

---

From: Dotzero <[email-masked]>
Date: Thu, 13 Aug 2020 21:43:08 -0400

On Thu, Aug 13, 2020 at 8:23 PM Murray S. Kucherawy <[email-masked]>
wrote:

> "DISCUSS" shouldn't really be a joke. draft-crocker-dmarc-sender suffers
from a similar problem as PRA in the SenderId draft. There is no way to
validate that the specific intermediary is authorized by the (From) domain
originating the email through it's generic signalling that it
authorizes intermediaries. This means that any source can emit a message
claiming to be a legitimate intermediary just as any source could game PR
to gain a neutral result. This raises a significant question as to the
value of this proposed draft. It essentially reverts to depending on
reputation as to whether the intermediary's assertions (I'm really really
trustworthy) should be accepted. One could achieve similar outcomes using
only reputation and local policy override of DMARC policy.

The only way a scheme along the lines of the proposed one would be if the
specific intermediary were authorized either through a seperate DKIM
signing of a field (with the intermediary domain ) that would remaintact
even if the DKIM signing of the entire message were broken by the
(authorized) intermediary.

The proposed approach is easily abusable by individuals with malicious
intent.

Michael Hammer

---

From: "John Levine" <[email-masked]>
Date: 13 Aug 2020 22:08:06 -0400

In article <CAJ4XoYfpGMUmkDkQYN0qZeNFi_xZjfR=[email-masked]> you write:
>to gain a neutral result.

That's a feature, not a bug. I want recipients to be able to assess
the mail my lists send on its own merits.

>One could achieve similar outcomes using

Only if you believe that the domain on the From: line is automatically
more credible than the one on the Sender: line. The whole third party
problem is that the people sending their mail through lists or
whatever are in fact doing so legitimately, but for various reasons
their organizations' DMARC policies lie and say they aren't.

R's,
John

---

From: Dotzero <[email-masked]>
Date: Fri, 14 Aug 2020 04:27:03 -0400

On Thu, Aug 13, 2020 at 10:08 PM John Levine <[email-masked]> wrote:

> In article <CAJ4XoYfpGMUmkDkQYN0qZeNFi_xZjfR=
> [email-masked]> you write:

And recipient domains do just that using local policy override. DMARC
policy is at best a request to the Validator/Receiving Domain. If a
Validator/Receiving Domain chooses to honor the published DMARC policy for
a domain such as p=reject, then they are in fact assessing the mail your
lists send based on the merits as they see them. The same goes if they
decide to not honor that published DMARC policy and accept mail from your
lists. Earlier in my DMARC journey I felt that MLMs should adjust and send
list mail as themselves. Now I have come to the conclusion that they should
reject list submissions from accounts at domains which publish a DMARC
policy of p=reject. Domains should not be able to externalize their
internal problems to others.

> their organizations' DMARC policies lie and say they aren't.

I think you are misusing the term "credible". Domains which are publishing
p=reject policies are making an assertion regarding mail purporting to be
authorized by their domain. It is not an assertion that their mail is
"good" or should be delivered to a recipient or even given preferential
treatment with regard to filters or policy. The assertion is simply that
mail purporting to be authorized by my domain must pass either SPF or DKIM
validation or else we request that in the event of neither of these
properly validating for a particular email message, please reject this
message. Don't think of it as being about "legitimate" or "not legitimate".
There is a certain (normally small) amount of mail that fails to validate
even when it passes directly from the outbound MTA to the recipient
domain's MTA. The sending domain is accepting that this otherwise valid
mail may (SHOULD?) be rejected by the receiving domain. The organizations
DMARC policies aren't lying. They are simply saying "If this then that."

This ultimately goes back to the elephant in the room. Does an individual
user's use of an account at a domain trump the organization's right to
define how an account at a domain may/should be used? I absolutely agree
that in an ideal world this issue should not be externalized yet here we
are. This is why I made the point above that lists should respect DMARC
policy and not accept submissions from domains with DMARC p=reject
policies. It becomes "Not your circus and not your monkey". and forces the
problem back to the domain and it's users. If an MLM isn't modifying the
message then the DKIM signature should survive and this discussion is
irrelevant. I think this covers the range of MLM use cases that have been a
topic of discussion. If the MLM admin really wants to poke those domains
publishing p=reject then they can respond to user subscribe attempts or
submissions that are rejected with an explanation that they need to go have
a meaningful discussion with their mail admin/IT staff/domain account
provider or whoever is responsible for publishing p=reject for tht domain
but still allowing users to sign up for MLMs or attempt to use other
intermediaries. popcorn is of course optional.

Michael Hammer

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 14 Aug 2020 11:21:12 +0200

On 2020-08-14 10:27 a.m., Dotzero wrote:
>> In article <[email-masked]> you write:
>>> "DISCUSS" shouldn't really be a joke. [...]

Adopting the I-D should boost the discussion, not hamper it.  No 
reason to discuss about adoption...

> And recipient domains do just that using local policy override.
> DMARC policy is at best a request to the Validator/Receiving
> Domain. If a Validator/Receiving Domain chooses to honor the
> published DMARC policy for a domain such as p=reject, then they are
> in fact assessing the mail your lists send based on the merits as
> they see them. The same goes if they decide to not honor that
> published DMARC policy and accept mail from your lists.

Agreed.  However, local policy override based on unspecified external 
sources is not easy for medium-small domains.

> Earlier in my DMARC journey I felt that MLMs should adjust and
> send list mail as themselves. Now I have come to the conclusion
> that they should reject list submissions from accounts at domains
> which publish a DMARC policy of p=reject.

Oh, in case, users can get another freemail account, or use trash 
email addresses.  Should the email infrastructure depend on the 
existence of such operators?

IMHO, a myriad of medium-small domains is more robust and more 
reliable than a few gorillas managing the whole world communications.

> Domains should not be able to externalize their internal problems
> to others.

You're sticking to the original concept that DMARC protection shall 
only be granted to heavily abused domains which don't host users' 
mailboxes.  People's email must be spoofable.  Why?

Best
Ale
--

---

From: "Douglas E. Foster" <[email-masked]>
Date: Fri, 14 Aug 2020 11:08:56 GMT

Michael Hammer / Dotzero writes:

"Earlier in my DMARC journey I felt that MLMs should adjust and send list mail as themselves. Now I have come to the conclusion that they should reject list submissions from accounts at domains which publish a DMARC policy of p=reject. Domains should not be able to externalize their internal problems to others."

My DMARC reports show no authorized transactions being rejected, but I do have two servers in Japan that are actively spoofing my organization's identity.  How is that an "internal" problem?

DF

---

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

On Fri, Aug 14, 2020 at 7:09 AM Douglas E. Foster <fosterd=
[email-masked]> wrote:

> "Earlier in my DMARC journey I felt that MLMs should adjust and send list
> mail as themselves. Now I have come to the conclusion that they should
> internal problems to others."
>
>
> My DMARC reports show no authorized transactions being rejected, but I do
> have two servers in Japan that are actively spoofing my organization's
> identity.  How is that an "internal" problem?
>
> DF
>

How is that relevant to the discussion thread? Are they MLMs or other
intermediaries which your users are sending messages to/through? If not
then it sounds like DMARC is working exactly as intended for you as long as
validators/receivers are respecting your DMARC policy assertions.

Michael Hammer

---

From: Laura Atkins <[email-masked]>
Date: Fri, 14 Aug 2020 15:45:54 +0100

> On 14 Aug 2020, at 09:27, Dotzero <[email-masked]> wrote:
> 
>  Now I have come to the conclusion that they should reject list submissions from accounts at domains which publish a DMARC policy of p=reject. Domains should not be able to externalize their internal problems to others.

This effectively cuts off users at multiple ISPs from ever participating in mailing lists. Which is exactly what we’re trying to fix with this proposal. 

Just because a user has an address at a consumer mailbox provider that publishes p=reject does not make them a second class citizen banned from participating in any mailing list. 

laura 

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

Laura Atkins
Word to the Wise
[email-masked]
(650) 437-0741		

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

---

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

On Fri, Aug 14, 2020 at 10:46 AM Laura Atkins <[email-masked]>
wrote:

>  Now I have come to the conclusion that they should reject list
> submissions from accounts at domains which publish a DMARC policy of
> p=reject. Domains should not be able to externalize their internal problems
> to others.
>
>
> This effectively cuts off users at multiple ISPs from ever participating
> in mailing lists. Which is exactly what we’re trying to fix with this
> proposal.
>

Does the proposal actually fix the problem? Does the proposal actually fix
the problem without creating other problems? After reading an re-reading
Dave's draft, my conclusion is that the answer is no to both questions.

>
> Just because a user has an address at a consumer mailbox provider that
> publishes p=reject does not make them a second class citizen banned from
> participating in any mailing list.
>

You are conflating the provision of Internet connectivity  with the
provision of email services. That ship sailed a long time ago. There are a
number of ISPs which no longer provide email accounts/port 25 services. If
a user with an account at one of those domains wanted to use their login as
an email address are you suggesting that others should send responses to
that "email address" even though no MX is available for that account and
mail will never reach that user? It is clear to me that a domain
owner/admin has the right to determine how that domain will or will not be
used. The individual is not banned from ever participating in a mailing
list. They simply can't use an account from that particular domain. There
are plenty of other places they can get an email account from. They also
have the opportunity to tell their existing provider they are unhappy with
policy. Providers can and do change their policies. For the longest time,
the address block associated with Amazon Simple Mail Service was a swamp of
badness. Legitimate users and organizations started deciding to not use
other Amazon AWS services as a result of their mail being blocked. Amazon
got religion and started cleaning up their mess. So yes, even large players
can respond to market and community pressures.

I'm not the person who initially suggested MLMs reject users/email from
domains that publish p=reject. That was John Levine. Perhaps he was being
sarcastic, perhaps not. It is certainly a forcing mechanism. And that may
just be what is needed for domains to think carefully about how they
implement DMARC.

Michael Hammer

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

---

From: Laura Atkins <[email-masked]>
Date: Fri, 14 Aug 2020 17:35:14 +0100

> On 14 Aug 2020, at 17:18, Dotzero <[email-masked]> wrote:
> 
> 
> 
> On Fri, Aug 14, 2020 at 10:46 AM Laura Atkins <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
>> On 14 Aug 2020, at 09:27, Dotzero <[email-masked] <mailto:[email-masked]>> wrote:
>> 
> Does the proposal actually fix the problem? Does the proposal actually fix the problem without creating other problems? After reading an re-reading Dave's draft, my conclusion is that the answer is no to both questions. 

And that’s why we’re having this discussion, to determine if it does or not. 

> You are conflating the provision of Internet connectivity  with the provision of email services. That ship sailed a long time ago. There are a number of ISPs which no longer provide email accounts/port 25 services. If a user with an account at one of those domains wanted to use their login as an email address are you suggesting that others should send responses to that "email address" even though no MX is available for that account and mail will never reach that user?

I was speaking of companies like Yahoo and AOL, companies that provide email services and not internet connectivity. They publish p=reject and any solution that is ‘well, they just don’t get to use mailing lists” seems to create a problem. At one point, gmail announced they will be publishing p=reject, which meant users of 2 of the 3 major consumer mailbox providers would be prohibited from joining mailing lists. 

> It is clear to me that a domain owner/admin has the right to determine how that domain will or will not be used. The individual is not banned from ever participating in a mailing list. They simply can't use an account from that particular domain. There are plenty of other places they can get an email account from. They also have the opportunity to tell their existing provider they are unhappy with policy. Providers can and do change their policies. For the longest time, the address block associated with Amazon Simple Mail Service was a swamp of badness. Legitimate users and organizations started deciding to not use other Amazon AWS services as a result of their mail being blocked. Amazon got religion and started cleaning up their mess. So yes, even large players can respond to market and community pressures.
> 
> I'm not the person who initially suggested MLMs reject users/email from domains that publish p=reject. That was John Levine. Perhaps he was being sarcastic, perhaps not. It is certainly a forcing mechanism. And that may just be what is needed for domains to think carefully about how they implement DMARC.

That is not how the quoting came through on my client. I was attempting to be succinct and trim the message. Here’s the full email I was responding to. In my client you appear to be the one saying MLMs should reject anyone using a domain with p=reject. If the quoting was incorrect, I apologize for the mistake. 

> On Thu, Aug 13, 2020 at 10:08 PM John Levine <johnl@taugh..com <mailto:[email-masked]>> wrote:
> In article <CAJ4XoYfpGMUmkDkQYN0qZeNFi_xZjfR=[email-masked] <mailto:[email-masked]>> you write:
> And recipient domains do just that using local policy override. DMARC policy is at best a request to the Validator/Receiving Domain. If a Validator/Receiving Domain chooses to honor the published DMARC policy for a domain such as p=reject, then they are in fact assessing the mail your lists send based on the merits as they see them. The same goes if they decide to not honor that published DMARC policy and accept mail from your lists. Earlier in my DMARC journey I felt that MLMs should adjust and send list mail as themselves. Now I have come to the conclusion that they should reject list submissions from accounts at domains which publish a DMARC policy of p=reject. Domains should not be able to externalize their internal problems to others.
> 
> I think you are misusing the term "credible". Domains which are publishing p=reject policies are making an assertion regarding mail purporting to be authorized by their domain. It is not an assertion that their mail is "good" or should be delivered to a recipient or even given preferential treatment with regard to filters or policy. The assertion is simply that mail purporting to be authorized by my domain must pass either SPF or DKIM validation or else we request that in the event of neither of these properly validating for a particular email message, please reject this message. Don't think of it as being about "legitimate" or "not legitimate". There is a certain (normally small) amount of mail that fails to validate even when it passes directly from the outbound MTA to the recipient domain's MTA. The sending domain is accepting that this otherwise valid mail may (SHOULD?) be rejected by the receiving domain. The organizations DMARC policies aren't lying. They are simply saying "If this then that."
> 
> This ultimately goes back to the elephant in the room. Does an individual user's use of an account at a domain trump the organization's right to define how an account at a domain may/should be used? I absolutely agree that in an ideal world this issue should not be externalized yet here we are. This is why I made the point above that lists should respect DMARC policy and not accept submissions from domains with DMARC p=reject policies. It becomes "Not your circus and not your monkey". and forces the problem back to the domain and it's users. If an MLM isn't modifying the message then the DKIM signature should survive and this discussion is irrelevant. I think this covers the range of MLM use cases that have been a topic of discussion. If the MLM admin really wants to poke those domains publishing p=reject then they can respond to user subscribe attempts or submissions that are rejected with an explanation that they need to go have a meaningful discussion with their mail admin/IT staff/domain account provider or whoever is responsible for publishing p=reject for tht domain but still allowing users to sign up for MLMs or attempt to use other intermediaries. popcorn is of course optional.
> 
> Michael Hammer

laura 

Laura Atkins
Word to the Wise
[email-masked]
(650) 437-0741

---

From: "John Levine" <[email-masked]>
Date: 14 Aug 2020 12:42:37 -0400

>internal problems to others.

Isn't that exactly the mailing list problem?

>"good" or should be delivered to a recipient ...

No, it's an assertion that mail that's unaligned is unauthorized, and
a request to reject it. For mail that their users send through mailing
lists, that assertion is false and the request clearly not what the
organization and its users want. This is what I conclude from the
number of unhappy people to whom I have had to explain that their mail
is disappearing because their employer told recipient systems to do
so.

> This is why I made the point above that lists should respect DMARC
>policies. 

Lists have been around a lot longer than DMARC has. Perhaps you meant
to say that domains whose users participate in mailing lists should
not publish restrictive DMARC policies. If they don't want their users
to send mail to lists, they should tell their users not to send mail
to lists.

There are lots of organizations that actively want their employees to
participate in the IETF, to the extent that they give them paid time
for IETF activities, yet publish p=reject policies to cripple that
participation. I wish they would make up their minds.

R's,
John

---

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

> Isn't that exactly the mailing list problem?

No, that is the domains publishing a policy externally but not telling
their users "Don't do that" problem.

> is disappearing because their employer told recipient systems to do

 "clearly not what the organization and its users want."

Who am I going to believe, the organization and it's published policy or
you?

> to send mail to lists, they should tell their users not to send mail

I meant what I wrote. Domains who actively want their users to participate
in mailing lists or even passively accept that their users participate in
mailing lists shouldn't publish p=reject for the domain their users are
sending from or should take steps to migrate the users to another
domain/subdomain, etc. Conversely, if a domain IS publishing p=reject then
yes, they should be taking steps internally but I also believe others
should consider that domain's published policy as intentional and act
accordingly. I've never heard of a DMARC policy getting published due to
inaction. Someone with administrative rights actively published that policy.

> participation. I wish they would make up their minds.

Me too.

Michael Hammer

---

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

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

I do not support adoption of this draft as a working group document for
different reasons than I have seen expressed by others on the list.

If the Sender header field is to be used by DMARC in the manner
described in this draft, it should be an integral part of the DMARCbis
specification rather than a separate extension to it. In other words,
this should be an issue on the DMARC WG issue tracker rather than a
working group draft (and presumably eventual RFC). There are enough
different combinations of originators and receivers that might use
Sender (which the chart in Section 2 begins to describe) that we don't
need the ongoing ambiguity of whether the receiver does or does not
implement this as an extension.

I have other comments on the proposal, but will stop here as they are
not directly germane to the question of adoption.

-Jim

---

From: Brandon Long <[email-masked]>
Date: Fri, 14 Aug 2020 15:44:59 -0700

On Fri, Aug 14, 2020 at 12:09 PM Jim Fenton <[email-masked]> wrote:

> If the Sender header field is to be used by DMARC in the manner described
> in this draft, it should be an integral part of the DMARCbis specification
> rather than a separate extension to it. In other words, this should be an
> issue on the DMARC WG issue tracker rather than a working group draft (and
> presumably eventual RFC). There are enough different combinations of
> originators and receivers that might use Sender (which the chart in Section
> 2 begins to describe) that we don't need the ongoing ambiguity of whether
> the receiver does or does not implement this as an extension.
>

+1

If DMARC wasn't experimental, maybe I could see adding it separately, but
this seems like a fairly fundamental change and shouldn't just be a
bolt-on... especially since as written this appears to undermine the
existing DMARC.. ie if DMARC is "apply this policy to these messages" and
this addition says "nah, don't apply them to some of those messages".

Brandon

---

From: Alessandro Vesely <[email-masked]>
Date: Sat, 15 Aug 2020 09:46:44 +0200

On 2020-08-14 7:04 p.m., Dotzero wrote:
>> In article <[email-masked]> you write:
>>> [...]
>>
>> Lists have been around a lot longer than DMARC has.

That doesn't grant lists any extra right.  Others consider current 
global usage as a priority gauge.

>> Perhaps you meant to say that domains whose users participate in
>> mailing lists should not publish restrictive DMARC policies. If
>> they don't want their users to send mail to lists, they should
>> tell their users not to send mail to lists.

Should they file lawsuits against online infringers?

> domain/subdomain, etc.

Why people's mailboxes must be spoofable?

Syllogism goes like so:  Mailing list must not accept strict DMARC 
policies, humans may happen to use mailing lists, therefore email 
domains which hosts mailboxes used by humans must not publish strict 
DMARC policies.  Is that really what we seek?  I hope not.

This is not the mailcore WG where they have to bring to full standard 
a time-honored paper.  We're talking about a protocol that is gaining 
adoption slowly as it has some troubles.  It's going to be Proposed 
Standard anyway.  Fixes may go as far as introducing Sender:.  In such 
a scenario, why should we stick to the restricted p=none except 
transactional?

> Conversely, if a domain IS publishing p=reject then yes, they
> should be taking steps internally but I also believe others should
> consider that domain's published policy as intentional and act 
> accordingly. I've never heard of a DMARC policy getting published
> due to inaction. Someone with administrative rights actively
> published that policy.

Possibly, that policy was pushed for security reasons.  We may say 
they don't know what they're doing.  They may say the same of us.

If DMARC cannot secure people's mailboxes, perhaps we should invent a 
different protocol.  It may still be based on SPF and DKIM 
authentication.  And still be called DMARC, no?

>> participation. I wish they would make up their minds.

We could make up our minds as well...

Best
Ale
--

---

From: Alessandro Vesely <[email-masked]>
Date: Sat, 15 Aug 2020 09:59:09 +0200

> implement this as an extension.

100% agreed.  However, since I haven't yet understood how exactly the 
spec is going to be split among various I-Ds, I voted for adoption in 
order to boost discussion.

Best
Ale
--

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 15 Aug 2020 02:02:06 -0700

Emphatically hatless:

> global usage as a priority gauge.

This line of thinking has bothered me for a long time.

Imagine you're a large soft drink manufacturer.  Your delicious, popular
product is sold in grocery stores the world over, sometimes directly from
your production line, sometimes via a local reseller.  Your sales team does
one or the other depending on the use case.  Business has been good for a
generation or two.  One day you decide you don't like resellers anymore
because some of them mis-promote your product, so you somehow arrange that
the cans in the stores that passed through resellers suddenly and randomly
begin invalidating themselves by bursting, making a mess of the store and
soaking customers.  Other products nearby are also ruined.  This reflects
poorly on the resellers, some of whom are forced to stop doing business
with you.  Stores get angry and are forced to reconsider doing business
with you as well, but you're big and popular and so many of them have to
deal with your mess on an ongoing basis.  Many customers take their
business elsewhere; the stores suffer.

The argument here appears to be that is that this is justified, because the
ecosystem of manufacturers, grocery stores, resellers, and customers that
has existed for as long as you can remember has no right to operate that
way if you suddenly decide you don't want it to; it's your brand, and your
word about your brand is final irrespective of how you choose to enforce
it.  You're suddenly, for reasons you feel are legitimate, asserting that
the ecosystem was broken to begin with despite the fact that you've been a
willing participant for decades, and therefore you are at liberty to
disrupt it (though, admittedly, you may have been unaware of the blast
radius of doing so).

Now, you may be right that the ecosystem was built on the incorrect premise
that domain names don't need to be treated as sacrosanct.  (Let's ignore
for the moment the stuff about hindsight.)  But that assertion clearly
differs from the well-established foundation upon which a great deal rests
today.  It is far from trivial to change that now.  It's possible to do, to
be sure, but dropping it into the world overnight has a hugely disruptive
impact.  Such a change needs to be an evolution, with the cooperation and
collaboration of a preponderance of the participants, not a philosophical
light switch you get to throw and expect everyone else to conform.

I don't want any more soda on me.

I don't know about "must", but changing the fundamental assumption that
it's acceptable in some cases for X to pretend to be Y (which is what MLMs
do), at X's discretion, is a tectonic change that should have been rolled
out with more community collaboration and grace than it was.  I think we
need to be more considerate of that fact if there is to be progress.

> DMARC policies.  Is that really what we seek?  I hope not.

It is our current reality, and in my humble opinion, we've nobody to blame
but ourselves.

-MSK, participating.

---

From: Alessandro Vesely <[email-masked]>
Date: Sat, 15 Aug 2020 12:32:25 +0200

> It is our current reality, and in my humble opinion, we've nobody to blame

The workarounds we have on the table, to standardize From: rewriting 
possibly copying the original From: value to some other field 
(Author:, To:, Reply-To:), to verify DKIM modulo transformations, and 
to accept a tunable set of Sender:'s do have the potential to smooth 
enough harshness and thereby avoid that cans which invalidate 
themselves mess up the store and ruin nearby products, don't they?

The first one of them has already proved its effectiveness.  If X 
pretends to be Y, it must do so in a verifiable, uncloakable way.  How 
processes which rely on the cloak can still believe it has to be 
worked out case by case.  The more alternatives we provide, the more 
likely one of them can suit a given case.

Best
Ale
--

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 15 Aug 2020 09:49:27 -0700

> themselves mess up the store and ruin nearby products, don't they?

They are all worthy of consideration, to be sure.  But that's not the thing
to which I was objecting.

The premise that MLMs have actually been long-tolerated abusers is a flawed
one, in my opinion.  I actually used to think the same thing back in the
RFC 4871 era, but I no longer agree.

-MSK

---

From: Dave Crocker <[email-masked]>
Date: Sat, 15 Aug 2020 11:12:18 -0700

On 8/15/2020 3:32 AM, Alessandro Vesely wrote:
> If X pretends to be Y,

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

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

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

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

>RFC 4871 era, but I no longer agree.

The same thing happens over and over. Someone invents a mail
authentication scheme which works for a lot of mail, but not all mail.
Then they roll it out, and its enthusiasts blame the victim as they
try to redefine the mail that it doesn't handle as "spoofed" or
otherwise illegimate.

This happened with SPF, and it's sure happening again with DMARC.

Can't wait to see what the next magic bullet aimed at our foot is.

R's,
John

---

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

Completely agree.

Please consider the environment before reading this message.
John Levine, [email-masked] 

> On Aug 15, 2020, at 14:12, Dave Crocker <[email-masked]> wrote:
> 
> If I put my gmail address into the from field, there is no pretending, no matter what platform I am using.
> 
> This continuing practice of characterizing valid use as if it were spoofing or pretending has been a major impediment to constructive discussion in the industry.
> 
> d/
> 
> -- 
> Dave Crocker

---

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

> If DMARC wasn't experimental, maybe I could see adding it separately, 
> but this seems like a fairly fundamental change and shouldn't just be 
> a bolt-on

Without suggesting a preference, it's worth considering nature/implication:

1. Separate

    DMARCbis is likely to be small changes on the existing spec and 
incorporation of something like my draft's changes could  a) 
destablilize the effort, and b) make the bis effort take significantly 
longer.  Also, my proposal is a lot more fragile than the base DMARC 
spec, both in terms of possible technical issue and possible operational 
issues.

2. Integrated

    Merging them makes it more likely that the result really is 
integrated and seamless.

d/

---

From: "Douglas E. Foster" <[email-masked]>
Date: Sat, 15 Aug 2020 22:33:38 GMT

Based on the discussions here, it appears that the notion of From address validation was envisioned from the beginning Sender Authentication discussions.    We have written evidence that Form address validation was anticipated in the DKIM and ATPS RFCs prior to DMARC.    So we have more than a decade of warnings that From address validation was coming.   While not everybody has time to read every RFC, the Mailing List trade press must have should have been reporting on it as something to watch.

Even after DMARC was in use, it appears that nobody in the mailing list community felt inconvenienced until the AOL/Yahoo hack and their decision to implement DMARC with p=reject.   This was the moment of Unhappy Surprise.    Bad guys had obtained many valid email addresses, so one of the concerns was how to prevent them from spoofing those users to send spam.   They could not use those address in the SMTP address because of SPF, but only DMARC could prevent those addresses from being misused in the Message From address.     It was the obvious thing to do and it would have been reckless for them to do otherwise.   Can you at least admit that the mailing list community was surprised because they failed to prepare for this contingency?   

But that moment is now in the rear view mirror.    Mailing lists can get delivery to all subscribers by confirming to the requirements of the DMARC-participating domains, by using their own domain in the From address, at least for those domains.    I assume that there are still mailing list operation that are not unable to comply with DMARC-participant expectations, because they have failed to upgrade.   But an individual organization’s failure to adapt is not a problem worthy of a standards body.   I liked XP just fine and hated Vista, like Windows7 OK but hated Windows 8.   But Microsoft killed support for XP and Windows 7 and my organization is adapting.    Life is unfair.  COVID-19 is unfair and has caused a lot of problems.   Every organization has problems, and we all have jobs so that we can help solve them.    The time to cry in your beer is over.  Mailing lists have a interoperability solution, and they should use it whether they like it or not, because that is what is necessary to get their mail delivered according to the requirements of the recipient organization.    As a result, mailing list operators really have no standing in this discussion, although they can certainly speak as unhappy individual users and on behalf of their unhappy users.  

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

This project was supposed to discuss moving DMARC from informational to standards track.   It has been hijacked by those who, to paraphrase Shakespeare, “have not come to praise DMARC, but to bury it.”   This has been abetted by the chair’s assertion that we must square a circle – meet the MLs requirement for them to impersonate without authorization while continuing to advance the DMARC requirement to prohibit impersonation without authorization.

As part of that hijacking, we have been inundated by Mr. Crocker’s assertions that the message From Address does not matter.  All the years of theoretical analysis that preceded DMARC and all of the operational success from implementations of DMARC are just wrong, simply because he says so.   Worse yet, he asserts without justification that the message From address should be unimportant to everybody except mailing list subscribers, for the simple reason that the Message From is so very important to his Mailing List subscribers.   It is comparable to asserting that the earth is flat, for everyone except astronauts.    This is sheer nonsense.

More importantly, this discussion has failed to address the actual objective, which is to solve the asserted Mailing List problem as it relates to AOL/Yahoo/Verizon.   That enterprise does not seem to be involved in this process, and no one has offered reason why they will be swayed by anything said here.    The strategy seems to be that if we tell these people how stupid they are, that they will do whatever we tell them they must do, even if the solution is to weaken security for everyone on the Internet.    That is not a winning strategy.

DMARC has been mandated by at least three national governments,, by a variety of businesses, and by this one consumer-oriented email hosting service.   It is here to stay, and any extensions to the specification will need to improve security, not weaken it for the benefit of a special interest group.

Instead, we should be anticipating that the U.S. government will begin mandating DMARC for its contractors, in phases based on contractor categories.    Simply requiring it for Department of Defense contractors would be sufficient to include most of the major research-oriented universities.   But every school that takes student loan payments is also considered a government contractor, which covers almost all of them.    Every branch of state and local government also feeds from the federal trough, and concerns about election meddling means that they are likely targets for voluntary or required implementation of DMARC.   Essentially every health care institution is also a government contractor, because they take payments from Medicare or Medicaid, usually both.

It is time to begin a discussion rooted in what is feasible, and what is appropriate for IETF to undertake.

----------------------------------------
From: "Murray S. Kucherawy" <[email-masked]>
Sent: 8/15/20 5:02 AM
To: Alessandro Vesely <[email-masked]>
Cc: IETF DMARC WG <[email-masked]>, John Levine <[email-masked]>, Dotzero <[email-masked]>
Subject: Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field
Emphatically hatless:

Imagine you're a large soft drink manufacturer.  Your delicious, popular product is sold in grocery stores the world over, sometimes directly from your production line, sometimes via a local reseller.  Your sales team does one or the other depending on the use case.  Business has been good for a generation or two.  One day you decide you don't like resellers anymore because some of them mis-promote your product, so you somehow arrange that the cans in the stores that passed through resellers suddenly and randomly begin invalidating themselves by bursting, making a mess of the store and soaking customers.  Other products nearby are also ruined.  This reflects poorly on the resellers, some of whom are forced to stop doing business with you.  Stores get angry and are forced to reconsider doing business with you as well, but you're big and popular and so many of them have to deal with your mess on an ongoing basis.  Many customers take their business elsewhere; the stores suffer.

The argument here appears to be that is that this is justified, because the ecosystem of manufacturers, grocery stores, resellers, and customers that has existed for as long as you can remember has no right to operate that way if you suddenly decide you don't want it to; it's your brand, and your word about your brand is final irrespective of how you choose to enforce it.  You're suddenly, for reasons you feel are legitimate, asserting that the ecosystem was broken to begin with despite the fact that you've been a willing participant for decades, and therefore you are at liberty to disrupt it (though, admittedly, you may have been unaware of the blast radius of doing so).

Now, you may be right that the ecosystem was built on the incorrect premise that domain names don't need to be treated as sacrosanct.  (Let's ignore for the moment the stuff about hindsight.)  But that assertion clearly differs from the well-established foundation upon which a great deal rests today.  It is far from trivial to change that now.  It's possible to do, to be sure, but dropping it into the world overnight has a hugely disruptive impact.  Such a change needs to be an evolution, with the cooperation and collaboration of a preponderance of the participants, not a philosophical light switch you get to throw and expect everyone else to conform.

I don't know about "must", but changing the fundamental assumption that it's acceptable in some cases for X to pretend to be Y (which is what MLMs do), at X's discretion, is a tectonic change that should have been rolled out with more community collaboration and grace than it was.  I think we need to be more considerate of that fact if there is to be progress.

It is our current reality, and in my humble opinion, we've nobody to blame but ourselves.

-MSK, participating.

---

From: "John Levine" <[email-masked]>
Date: 15 Aug 2020 18:53:06 -0400

In article <[email-masked]> you write:
>Based on the discussions here, it appears that the notion of From address validation was envisioned from the
>beginning Sender Authentication discussions.    We have written evidence that Form address validation was
>anticipated in the DKIM and ATPS RFCs prior to DMARC. 

Not really. DKIM was deliberately designed not to be tied to any
visible part of the message. ADSP was a poorly designed hack that was
never implemented other than small experiments, and that I don't think
many people understood. I got a lot of grief for making the most
strict policy "discardable" even though that's obviously what it was.

R's,
John
-- 
Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

---

From: "Douglas E. Foster" <[email-masked]>
Date: Sat, 15 Aug 2020 23:36:40 GMT

My comments about From validation were based on the wording of the RFCs, so I stand by what I said.
 
But are your really arguing that no one in the Mailing List business paid attention to the concerns about the fraud and spoofing problems with email?

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

That is the problem we should be worried about.   And that is why I am letting my emotions show.  This WG is playing the fiddle while Rome burns.

Doug

----------------------------------------
From: "John Levine" <[email-masked]>
Sent: 8/15/20 6:53 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

R's,
John

---

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

On 8/15/2020 3:33 PM, Douglas E. Foster wrote:
> Consequently, the real problem before us becomes the existence of 
> users who are unhappy because the From address on some mail does not 
> meet their preferences.    I have to ask why that is a problem worthy 
> of a standards body? 

Who, exactly, do you think these services are /for/?

d/

---

From: "John Levine" <[email-masked]>
Date: 15 Aug 2020 22:18:56 -0400

>But are your really arguing that no one in the Mailing List business paid attention to 
> the concerns about the fraud and spoofing problems with email?

I am unaware of any mailing lists causing fraud and spoofing problems
in email, so no more than anyone else. (Sending along real mail in
ways that DMARC cannot describe is neither fraud nor spoofing, of
course.)

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

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

R's,
John

>My comments about From validation were based on the wording of the RFCs, so I stand by what I said.

I hope you will forgive me if I do not accept your interpretation of RFCs that I wrote.

---

From: Alessandro Vesely <[email-masked]>
Date: Sun, 16 Aug 2020 10:23:45 +0200

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

> no matter what platform I am using.

That conflicts with the coarse-grained authentication strategy, 
established at the FTC Email Authentication Summit in November 2004, 
as Doug recalled.  Your gmail address needs to be authenticated by 
gmail.  Sending From: bbiw.net, SPF-authenticated as dcrocker.net, and 
whitelisted as yet another domain (songbird.com) can hardly be 
verified.  There is no "pretending", since it's you, but it is not 
formally distinguishable from spoof, is it?

> discussion in the industry.

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

Of course, the alternative is to keep email as a casual, unreliable, 
unofficial means of communication.  I'm not sure the latter is 
realistic, given current trends.  Are we sticking our heads in the sand?

Best
Ale
--

---

From: Alessandro Vesely <[email-masked]>
Date: Sun, 16 Aug 2020 11:41:24 +0200

On Sun 16/Aug/2020 10:23:45 +0200 I wrote:
> FTC Email Authentication Summit in November 2004, as Doug recalled.

Sorry, of course I meant Michael.

Best
Ale
--

---

From: Alessandro Vesely <[email-masked]>
Date: Sun, 16 Aug 2020 12:15:03 +0200

On Sun 16/Aug/2020 04:18:56 +0200 John Levine wrote:
>> This morning I had a conversation with the CEO of a company that
>> was hit by ransomware which arrived with the help of a single
>> email.   He is slowly getting his company back after paying a lot
>> of money to people who want to destroy us. >
> I think you would be dismayed how little of that would be stopped
> by more stringent DMARC policies. They use lookalike addresses, or
> they depend on MUAs that show the From header comments rather than
> the addresses. I once saw a very slick spear phish where the crook 
> registered the victim's domain name substituting "rn" for "m".

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

Best
Ale
--

---

From: Dave Crocker <[email-masked]>
Date: Sun, 16 Aug 2020 08:31:47 -0700

On 8/16/2020 1:23 AM, Alessandro Vesely wrote:
> On Sat 15/Aug/2020 20:12:18 +0200 Dave Crocker wrote:> On 8/15/2020 3:32 
> AM, Alessandro Vesely wrote:
> 
>>> If X pretends to be Y,
>>
>>
> established at the FTC Email Authentication Summit in November 2004, as 

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

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

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

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

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

> Sending From: bbiw.net, SPF-authenticated as dcrocker.net, and 

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

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

I have no idea what you are referring it.

d/

---

From: "John R Levine" <[email-masked]>
Date: 16 Aug 2020 11:44:16 -0400

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

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

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

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

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

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Alessandro Vesely <[email-masked]>
Date: Sun, 16 Aug 2020 20:03:46 +0200

On Sun 16/Aug/2020 17:31:47 +0200 Dave Crocker wrote:
>> On Sat 15/Aug/2020 20:12:18 +0200 Dave Crocker wrote:
>>> If I put my gmail address into the from field, there is no 
>>> pretending, no matter what platform I am using.
>>
>>
>> established at the FTC Email Authentication Summit in November
>> 2004, as Doug^W Michael recalled. >

They have to match at some point.

> interesting discussions, but that's all.

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

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

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

>> Your gmail address needs to be authenticated by gmail. 
> 
> Good grief, no.  There is no system rule to that effect.  DMARC 
> created that, but no policy before it was in place, never mind accepted.

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

> fact that valid uses are valid.

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

> I have no idea what you are referring it.

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

Best
Ale
--

---

From: Dave Crocker <[email-masked]>
Date: Sun, 16 Aug 2020 11:16:17 -0700

> They have to match at some point.

it would be nice, wouldn't it?

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

> domain-level authentication as the promising strategy to counter email 

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

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

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

Finally found that you meant Herr Hammer.

> operators seem to have accepted it.  Why cannot we accept it too?

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

> recipients to verify such validity.

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

d/

---

From: "John R Levine" <[email-masked]>
Date: 16 Aug 2020 14:16:50 -0400

> They have to match at some point.

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

>> 2. There was nothing 'established' at that event.  There were interesting 
>> discussions, but that's all.
>
> domain-level authentication as the promising strategy to counter email abuse?

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

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

Please review the previous bazillion messages on this topic.

Regards,

---

From: Laura Atkins <[email-masked]>
Date: Mon, 17 Aug 2020 10:46:55 +0100

> On 16 Aug 2020, at 19:16, John R Levine <[email-masked]> wrote:
> 
>>>> That conflicts with the coarse-grained authentication strategy, established at the FTC Email Authentication Summit in November
> Sorry, that's just wrong.  There's no technical reason a mail message can't have any identifiers the sender wants.
> 
>>> 2. There was nothing 'established' at that event.  There were interesting discussions, but that's all.
>> 
>> I wasn't there.  Can't it be considered the historic event that marked domain-level authentication as the promising strategy to counter email abuse?
> 
> No, it was just some political theatre.  We were already working on SPF and DKIM.

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

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

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

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

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

laura

Laura Atkins
Word to the Wise
[email-masked]
(650) 437-0741

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 17 Aug 2020 11:57:48 +0200

On Sun 16/Aug/2020 20:16:17 +0200 Dave Crocker wrote:
>>>> 2004, as Doug^W Michael recalled >>>

Separate but related.

>> I wasn't there.  Can't it be considered the historic event that 
>> marked domain-level authentication as the promising strategy to 
>> counter email abuse?
> 
> Reference to that event as if it 'established' anything is misguided, 
> at best.  The meetings were helpful, but not definitive.  And the 
> efforts at domain level authentication were wholly independent of 
> these events.

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

> government and, therefore, a signal that the government was concerned.

A noteworthy historical detail.

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

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

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

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

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

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

Best
Ale
-- 

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

---

From: Laura Atkins <[email-masked]>
Date: Mon, 17 Aug 2020 11:24:48 +0100

> On 17 Aug 2020, at 10:57, Alessandro Vesely <[email-masked]> wrote:
> 
>> Reference to that event as if it 'established' anything is misguided, at best.  The meetings were helpful, but not definitive.  And the efforts at domain level authentication were wholly independent of these events.
> 
> 
> Would it be still correct to mention that summit as a conspicuous event that testifies the emergence of domain-level authentication around the early 2000s?

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

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

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

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

What issue will only domain-level authentication solve? 

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

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

laura 

>>>>> Sending From: bbiw.net, SPF-authenticated as dcrocker.net, and whitelisted as yet another domain (songbird.com) can hardly be verified.  There is no "pretending", since it's you, but it is not formally distinguishable from spoof, is it?
>>>> 
>>>> Whether valid and invalid uses can be distinguished does not alter the fact that valid uses are valid.
>>> 
>>> The problem is to find the technical means that allow receivers and recipients to verify such validity.
>> Of course.  But when it's at the expense of valid use that has worked for 45 years, then those means are problematic.  Highly.
> 
> It seems to me most expenses have been paid already, for example this mailing list is applying From: rewriting.  We don't need to propose further restrictions.  To the opposite, there are means on the table[*] that can enable us to sketch a time horizon where From: rewriting can cease.
> 
> 16 years have passed since the FTC event, which is 1/3 of those 45. What I see looks much like a very mild shift.  Lazy operators have plenty of time before the semantic change is established, at some point in the medium-term future, if ever.

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

Laura Atkins
Word to the Wise
[email-masked]
(650) 437-0741

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 17 Aug 2020 13:25:36 +0200

> The forum page is off the FTC website, but the document links are 

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

A sentence says:

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

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

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

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

It seems we're still stuck midstream...

Best
Ale
--

---

From: Laura Atkins <[email-masked]>
Date: Mon, 17 Aug 2020 13:22:14 +0100

> On 17 Aug 2020, at 12:25, Alessandro Vesely <[email-masked]> wrote:
> 

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

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

>    it's something useful and can be deployed incrementally.

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

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

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

laura

Laura Atkins
Word to the Wise
[email-masked]
(650) 437-0741

---

From: Dotzero <[email-masked]>
Date: Mon, 17 Aug 2020 08:38:51 -0400

> interesting discussions, but that's all.

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

> that, but no policy before it was in place, nevermind accepted.

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

> fact that valid uses are valid.

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

Michael Hammer

---

From: Dotzero <[email-masked]>
Date: Mon, 17 Aug 2020 08:48:31 -0400

On Sun, Aug 16, 2020 at 2:03 PM Alessandro Vesely <[email-masked]> wrote:

> There was no such strategy established regardless of what one person
remembers.

> > interesting discussions, but that's all.

Agreed.

> domain-level authentication as the promising strategy to counter email

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

> > created that, but no policy before it was in place, never mind accepted.

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

> operators seem to have accepted it.  Why cannot we accept it too?

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

> own mail server could be a valid alternative.

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

Michael Hammer

---

From: Dotzero <[email-masked]>
Date: Mon, 17 Aug 2020 08:53:54 -0400

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

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

> operators

Are those bazillion messages authenticated? ;-)

Michael Hammer

---

From: Dotzero <[email-masked]>
Date: Mon, 17 Aug 2020 09:04:40 -0400

> event that testifies the emergence of domain-level authentication
As someone who was there, I would be reticent to make such a statement.

> A noteworthy historical detail.

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

> > semantics and operational policy of email.  Why can't THAT be accepted?

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

> spoofing.  To believe that such illusion will come true makes for a

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

> a consistent authentication protocol.

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

> point in the medium-term future, if ever.

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

Michael Hammer

---

From: Dave Crocker <[email-masked]>
Date: Mon, 17 Aug 2020 06:17:33 -0700

On 8/17/2020 2:57 AM, Alessandro Vesely wrote:
> Would it be still correct to mention that summit as a conspicuous event 
> that testifies the emergence of domain-level authentication around the 
> early 2000s?

No.

d/

---

From: Dotzero <[email-masked]>
Date: Mon, 17 Aug 2020 09:18:50 -0400

On Mon, Aug 17, 2020 at 8:22 AM Laura Atkins <[email-masked]>
wrote:

> And, 17 years on, we know that domain level authentication doesn’t
> actually help filter spam nor does it provide law enforcement with a potent
> tool for locating and identifying spammers. It was promising, it didn’t
> live up to the promise.
>
> There were a lot of thrown at the wall during those 3 days of talks. One
> of them was domain level opt-out. Another was a global opt-out list similar
> to the postal opt-outs run by the DMA. Another was a technology called
> TEOS. HashCash. The list of things we discussed as promising solutions was
> extensive. Just because we discussed a particular kind of solution does not
> mean that anything was decided. It also doesn’t mean that any particular
> solution mentioned was workable.
>
>
> We know, now, that turning on domain level protection does not stop
> phishing attacks against that company. It stops direct spoofing of the
> domain, but the phishers simply use a completely different domain. Just
> this weekend I got a PayPal phish. PayPal who helped invent DMARC are still
> getting spoofed and phished. Sure, the phishers aren’t using the
> paypal.com domain, but that doesn’t seem to have any effect on their
> success at stealing money from people.
>

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

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

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

Michael Hammer

---

From: Joseph Brennan <[email-masked]>
Date: Mon, 17 Aug 2020 09:45:03 -0400

On Mon, Aug 17, 2020 at 6:24 AM Laura Atkins <[email-masked]>
wrote:

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

Well said (I liked the poetic indentation too)

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

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

---
Joseph Brennan

---

From: Laura Atkins <[email-masked]>
Date: Mon, 17 Aug 2020 15:00:42 +0100

> On 17 Aug 2020, at 14:18, Dotzero <[email-masked]> wrote:
> 
>>> https://www.ftc.gov/sites/default/files/documents/public_events/ftc-spam-forum/transcript_day2.pdf <https://www.ftc.gov/sites/default/files/documents/public_events/ftc-spam-forum/transcript_day2..pdf>
> You raise an interesting point, Laura. Whatever "solutions" we put in place, the abusers/bad guys will evolve. One of the problems for the good guys (for some definition of good) is that standards work takes years (decades?)  while the bad  guys change their tactics at will. Crime existed before the Internet and will continue long after we are all dead and buried.

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

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

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

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

laura 

Laura Atkins
Word to the Wise
[email-masked]
(650) 437-0741

---

From: Dave Crocker <[email-masked]>
Date: Mon, 17 Aug 2020 07:26:54 -0700

On 8/17/2020 7:00 AM, Laura Atkins wrote:
>> forcing mechanism that instigated a lot of effort and innovation in 
>> the space. Some of those efforts fell by the wayside and some still 
>> persist.
>
> You think? I’m not sure I’d agree. I saw the workshop as mostly a 
> political (and educating the politicians) exercise. The effort and 
> innovation were already there and being done by a lot of people who 
> weren’t there. I’m kinda bemused by the importance folks have assigned 
> to it in relation to the vastly different email ecosystem we have today.
>

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

d/

---

From: Dotzero <[email-masked]>
Date: Mon, 17 Aug 2020 10:33:39 -0400

On Mon, Aug 17, 2020 at 10:01 AM Laura Atkins <[email-masked]>
wrote:

>> <https://www.ftc.gov/sites/default/files/documents/public_events/ftc-spam-forum/transcript_day2..pdf>
>>
> Totally agreed. The issue here is that DMARC is a fundamentally flawed
> model for preventing phishing. Phishers were adapting to mailbox provider
> filters even before DMARC and there was a lot of cousin and non-look-alike
> domain phishing even during the initial discussions. I know these issues
> were brought up during discussion of the protocol. Unfortunately, they
> weren’t sufficiently addressed and now we’re at a point where, to my mind,
> DMARC doesn’t fix anything while also breaking a lot of ways folks use mail.
>
>
DMARC fixes one thing and one thing only, direct domain abuse. Not cousin
domains, not homoglyphs and not a whole bunch of other things. It
was successful in achieving its intended purpose. It was initially
developed and deployed privately as a "private club". The intent in making
it a public standard was to enable any domain, regardless of size or
connections to be able to participate if that domain needed to fight direct
domain abuse, noting the caveats regarding individual user accounts vs
transactional email.

It’s a little late now to go back. I think this is an opportunity to think
> about the underlying technical problems as well as a chance to revisit the
> assumptions about how email is used. Discussing things like Dave’s drafts
> will give us a chance to talk about how people actually use email to
> communicate with one another. And how we can allow brands what they want
> without breaking email too much for the rest of us.
>
> innovation were already there and being done by a lot of people who weren’t
> there. I’m kinda bemused by the importance folks have assigned to it in
> relation to the vastly different email ecosystem we have today.
>
> I think this is a matter of perspective. DK was gaining
traction because...Yahoo! SPF was not that widely deployed (yet). I wrote
about the FTC being a forcing mechanism because of the threat of
regulation. The threat wasn't formal and it wasn't specific as to what it
meant, but it certainly got people's attention.

 Michael Hammer

---

From: Dotzero <[email-masked]>
Date: Mon, 17 Aug 2020 10:37:18 -0400

On Mon, Aug 17, 2020 at 10:27 AM Dave Crocker <[email-masked]> wrote:

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

Exactly. +1

Michael Hammer

---

From: Dave Crocker <[email-masked]>
Date: Mon, 17 Aug 2020 07:37:46 -0700

On 8/17/2020 7:33 AM, Dotzero wrote:
> DMARC fixes one thing and one thing only, direct domain abuse.

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

<rant>

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

</rant>

So...

DMARC fixes abuse of rfc5322.From field domains.

THAT is the only thing it does.

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

d/

---

From: Dotzero <[email-masked]>
Date: Mon, 17 Aug 2020 10:46:54 -0400

> sorts of ways that DMARC does not affect.

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

> <rant>
>
> A continuing and in my view fundamental problem with discussion in this
> space is the lack of careful and precise language when talking about
> actions and effects.
>
> </rant>
>
> So...
>
See above. I was even more specific than you were in terms of what DMARC
does.

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

Michael Hammer (Inaccurately referred to by you as Herr Hammer)

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 17 Aug 2020 19:48:28 +0200

> complexity that is beyond the ability of the average person. I'm not sure

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

Best
Ale
--

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 17 Aug 2020 20:23:31 +0200

On Mon 17/Aug/2020 16:00:42 +0200 Laura Atkins wrote:
> It’s a little late now to go back.

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

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

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

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

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

Best
Ale
--

---

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Mon, 17 Aug 2020 20:26:17 +0200

>> On 17 Aug 2020, at 16:47, Dotzero <[email-masked]> wrote:
> 
> 
> 
>>> It does no such thing.  Domains can still be 'directly' abused in all sorts of ways that DMARC does not affect.  
>>> 
>> 
>> Mea Culpa. You are correct that it only does so in the context of SPF and DKIM validation which protects rfc5322 From field domains and aligned rfc5321 Mail From domains (SPF).
>> <rant>
>> 
>> A continuing and in my view fundamental problem with discussion in this space is the lack of careful and precise language when talking about actions and effects.
>> 
>> </rant>
>> 
>> So...
>> 
> See above.. I was even more specific than you were in terms of what DMARC does. 
> Only when it is used in domains where there are individual user accounts and not (only) transactional mail uses. If I use a hammer (no pun intended) to pound in a screw, it doesn't make it the right tool for the job.
> 

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

/rolf

---

From: Dave Crocker <[email-masked]>
Date: Mon, 17 Aug 2020 11:28:08 -0700

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

to mix languages, au contraire.  I was being formal, as well as precise...

d/

---

From: Dotzero <[email-masked]>
Date: Mon, 17 Aug 2020 14:53:05 -0400

> to mix languages, au contraire.  I was being formal, as well as precise...

Apology accepted. ;-)

Michael Hammer

---

From: Dave Crocker <[email-masked]>
Date: Mon, 17 Aug 2020 12:00:29 -0700

> Apology accepted. ;-)

nein.  maaf.

d/

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 17 Aug 2020 17:36:38 -0700

Still as just me:

On Sat, Aug 15, 2020 at 3:34 PM Douglas E. Foster <fosterd=
[email-masked]> wrote:

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

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

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

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

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

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

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

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

None of this discussion seems invalid to me.

As part of that hijacking, we have been inundated by Mr. Crocker’s
> assertions that the message From Address does not matter.  All the years of
> theoretical analysis that preceded DMARC and all of the operational success
> from implementations of DMARC are just wrong, simply because he says so.
>
It's not simply because he says so.  At the time DMARC was on the drawing
board, the MUA game was different.  We talked about this a lot back then,
and it was discussed previously in this working group too.  These days,
there's evidence to suggest that the domain name is rarely visible.  If
that's true, I claim it's a valid thing to revisit whether DMARC as it's
currently designed is providing useful protection especially with respect
to the disruption it causes elsewhere.

> More importantly, this discussion has failed to address the actual
> objective, which is to solve the asserted Mailing List problem as it
> relates to AOL/Yahoo/Verizon.   That enterprise does not seem to be
> involved in this process, and no one has offered reason why they will be
> swayed by anything said here.    The strategy seems to be that if we tell
> these people how stupid they are, that they will do whatever we tell them
> they must do, even if the solution is to weaken security for everyone on
> the Internet.    That is not a winning strategy.
>
I think this is all a little hyperbolic and not especially constructive.

RFC 7489 was co-edited by a Yahoo engineer.  I'm pretty sure she's paying
attention, either here or in related industry trade groups.  The others are
probably at least being made aware of it via the latter.

The IETF is not the protocol police.  If you need evidence of this, simply
note that RFC 7489 was deployed despite who participated in its development
and how many consensus documents warned against its use in mail flows where
Mediators are present.

DMARC has been mandated by at least three national governments,, by a
> variety of businesses, and by this one consumer-oriented email hosting
> service.   It is here to stay, and any extensions to the specification will
> need to improve security, not weaken it for the benefit of a special
> interest group.
>
This sounds a lot like an argument from authority.

There is no doubt that anti-phishing technologies are critical, and it's no
surprise that a protocol characterized as effective against phishing is
being widely endorsed.  The question being proposed here is whether DMARC
actually still fits that bill given the current state of the industry.  I
suggest that this is a perfectly valid question, and I would really like
you to explain why it should be declared moot or off-topic.

Instead, we should be anticipating that the U.S. government will begin
> mandating DMARC for its contractors, in phases based on contractor
> categories.    Simply requiring it for Department of Defense contractors
> would be sufficient to include most of the major research-oriented
> universities.   But every school that takes student loan payments is also
> considered a government contractor, which covers almost all of them.
>  Every branch of state and local government also feeds from the federal
> trough, and concerns about election meddling means that they are likely
> targets for voluntary or required implementation of DMARC.   Essentially
> every health care institution is also a government contractor, because they
> take payments from Medicare or Medicaid, usually both.
>
Yes.  Wouldn't it be an atrocity if they bolted their security stories to a
lemon?

It is time to begin a discussion rooted in what is feasible, and what is
> appropriate for IETF to undertake.
>

There, we agree.

-MSK

---

From: Brandon Long <[email-masked]>
Date: Tue, 18 Aug 2020 16:21:47 -0700

> tool for locating and identifying spammers. It was promising, it didn’t

I don't understand this.  Virtually every spam rule we write these days
depends on information attached to the domain level authentication of an
email message.

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

> success at stealing money from people.

Do we have stats on that?

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

Brandon

---

From: Laura Atkins <[email-masked]>
Date: Wed, 19 Aug 2020 10:26:56 +0100

> On 19 Aug 2020, at 00:21, Brandon Long <blong=[email-masked]> wrote:
> 
> 
> 
> On Mon, Aug 17, 2020 at 5:22 AM Laura Atkins <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
>> On 17 Aug 2020, at 12:25, Alessandro Vesely <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> https://web.archive.org/web/20120603201012/https://www.ftc.gov/bcp/workshops/e-authentication/ <https://web.archive.org/web/20120603201012/https://www.ftc.gov/bcp/workshops/e-authentication/>
>> 
>> A sentence says:
>> 
> I don't understand this.  Virtually every spam rule we write these days depends on information attached to the domain level authentication of an email message.

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

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

You are correct and I wasn’t thinking. 

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

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

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

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

laura 

Laura Atkins
Word to the Wise
[email-masked]
(650) 437-0741

---

From: David I <[email-masked]>
Date: Thu, 20 Aug 2020 16:45:30 +0000

The draft is available here: https://datatracker.ietf.org/doc/draft-crocker-dmarc-sender/<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-crocker-dmarc-sender%2F&data=02%7C01%7Cdavid.i%40ncsc.gov.uk%7C8b6f69bd79a0456b083a08d83d605162%7C14aa5744ece1474ea2d734f46dda64a1%7C0%7C0%7C637326831179930300&sdata=essow9o1nmqARNXCr%2BUFkBhUwomyBq0E0dpxzzK7q9E%3D&reserved=0>

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

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

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

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

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

Regards,
David

This information is exempt under the Freedom of Information Act 2000 (FOIA) and may be exempt under other UK information legislation. Refer any FOIA queries to [email-masked]. All material is UK Crown Copyright ©

---

From: Jim Fenton <[email-masked]>
Date: Fri, 21 Aug 2020 12:09:42 -0700

> strict policy "discardable" even though that's obviously what it was.
And even with the kinder-and-gentler term "discardable" for its most
harsh policy option, ADSP was moved from Standards Track to Historic.
From
https://datatracker.ietf.org/doc/status-change-adsp-rfc5617-to-historic/ :

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

-Jim

---

From: Brandon Long <[email-masked]>
Date: Fri, 21 Aug 2020 14:18:09 -0700

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

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

Brandon

On Fri, Aug 21, 2020 at 12:10 PM Jim Fenton <[email-masked]> wrote:

> And even with the kinder-and-gentler term "discardable" for its most harsh
> policy option, ADSP was moved from Standards Track to Historic. From
> Is that not exactly the same situation with DMARC, except that the policy
> in question now is "reject" rather than "discardable"? Yes, it's just a
> keyword, but it reflects the semantics of the expected action as well.
>
> -Jim

---

From: Hector Santos <[email-masked]>
Date: Mon, 24 Aug 2020 02:00:10 -0400

> policy in question now is "reject" rather than "discardable"? Yes,
> it's just a keyword, but it reflects the semantics of the expected
> action as well.
>
> -Jim

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

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