Subject: [dmarc-ietf] Experiments

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 22 Sep 2021 13:30:29 -0700

Is anyone in a position to comment on the ARC and PSD experiments and how
they're progressing?  Deployment status?  Data acquired thus far?

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 22 Sep 2021 20:59:07 +0000

I can comment on the status of PSD.

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 23 Sep 2021 00:03:39 -0700

> I can comment on the status of PSD.

Please do!

---

From: "Brotman, Alex" <[email-masked]>
Date: Thu, 23 Sep 2021 21:07:43 +0000

Murray,

We’ve started (relatively recently, in volume) logging ARC data so we can try to make some informed decisions going forward.  We’re not yet acting on anything as a result, nor writing into the message. We’re also not doing anything when mail is being forwarded.  We’ll hopefully have more information/data available to share in the future (may not be the very near future given other projects going on).   This isn’t a guarantee that we’ll fully adopt ARC in the future, but enough to say we’re logging/analyzing things.

Random thing while looking at some data just now .. At least one message apparently came through with seven ARC sets.

Let me know if there’s anything I can answer at this point.

--
Alex Brotman
Sr. Engineer, Anti-Abuse & Messaging Policy
Comcast

From: dmarc <[email-masked]> On Behalf Of Murray S. Kucherawy
Sent: Wednesday, September 22, 2021 4:30 PM
To: IETF DMARC WG <[email-masked]>
Subject: [dmarc-ietf] Experiments

Is anyone in a position to comment on the ARC and PSD experiments and how they're progressing?  Deployment status?  Data acquired thus far?

-MSK

---

From: Trent Adams <[email-masked]>
Date: Thu, 23 Sep 2021 21:29:55 +0000

Piling onto Alex's response... we have some ARC functionality deployed and servicing customers.  I'm currently looking into what useful data we can extract and share what we've learned from the implementation (which may lead to some useful topics to discuss in more depth).

In a related note... an early examination seems to underscore the need to more guidance about how to interpret ARC sets.  As Alex pointed out... there are some messages with way more sets than can be used to make a reasonable determination about the provenance of the message.  So, at the very least, I think we may need to develop some ancillary documents to support broader adoption.

More as it develops,
Trent

From: dmarc <[email-masked]> on behalf of "Brotman, Alex" <Alex_Brotman=[email-masked]>
Date: Thursday, September 23, 2021 at 3:08 PM
To: "Murray S. Kucherawy" <[email-masked]>, IETF DMARC WG <[email-masked]>
Subject: Re: [dmarc-ietf] Experiments

Murray,

-MSK

---

From: Douglas Foster <[email-masked]>
Date: Thu, 23 Sep 2021 21:04:58 -0400

For messages sent from Office365, Microsoft applies an initial ARC set, and
declares the message to be DMARC-compliant.    I do not think Microsoft
should be passing judgement on messages that it is originating, or
attributing an SPF result to a message that was only just submitted with
SMTP AUTH.

But this situation does point to the complexity of trusting and
interpreting the ARC chain, which is unfortunate.

On Thu, Sep 23, 2021 at 5:08 PM Brotman, Alex <Alex_Brotman=
[email-masked]> wrote:

> Murray,
>
>
>
> We’ve started (relatively recently, in volume) logging ARC data so we can
> try to make some informed decisions going forward.  We’re not yet acting on
> anything as a result, nor writing into the message. We’re also not doing
> anything when mail is being forwarded.  We’ll hopefully have more
> information/data available to share in the future (may not be the very near
> future given other projects going on).   This isn’t a guarantee that we’ll
> fully adopt ARC in the future, but enough to say we’re logging/analyzing
> things.
>
> Random thing while looking at some data just now .. At least one message
> apparently came through with seven ARC sets.
>
>
>
> *From:* dmarc <[email-masked]> *On Behalf Of * Murray S. Kucherawy
> *Sent:* Wednesday, September 22, 2021 4:30 PM
> *To:* IETF DMARC WG <[email-masked]>
> *Subject:* [dmarc-ietf] Experiments
>
>
>
> _______________________________________________
> dmarc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmarc
>

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 23 Sep 2021 21:43:25 -0400

> > I can comment on the status of PSD.

There is progress, but it is still early to expect much in the way of 
information.  Keep in mind that RFC 9091 is less than two months old.

As most of you will probably recall from the discussion around PSD DMARC, the 
ICANN managed TLDs (essentially everything except ccTLDs and a few special 
cases like .mil and .gov) require permission to publish via non-IETF 
processes.

I'm aware of three PSDs which currently publish records.  Both .gov.uk and 
.mil have had records published for some time.  Additionally, .police.uk 
published a record in July of this year.  I understand that .gov plans to 
publish their record this month.

Until we see publication from an ICANN managed TLD, I don't think we'll have 
enough variety to seriously begin the assessments contemplated in the 
experiment section of RFC 9091, so it's difficult to predict how soon we will 
have conclusions.  This isn't the right place to go into details on non-IETF 
processes.

Based on what I've heard so far, the PSD records are being queried and there 
is some feedback reporting, so I'm confident we'll get data once we get a 
little further on deployment.

If anyone is aware of others, please let me know.

Scott K

---

From: Ken O'Driscoll <[email-masked]>
Date: Fri, 24 Sep 2021 10:55:47 +0000

Well, I have had a deliverability related encounter with ARC in the wild, and can report that ARC is actively being used by Zoho.

A client was using Zoho for their service desk and messages started going missing. The way these service desks work is that you forward say [email-masked] to a unique Zoho supplied email address which goes to your service desk queue.

On investigation, it was determined that the only messages going missing were those originating from domains with an enforcing DMARC policy and non-aligned/non-existent/broken DKIM.

Correspondence with Zoho’s customer service revealed that they a) have implemented ARC, b) expect every mailbox provider to also have implemented ARC, and c) are making filtering decisions on that belief. They appear to be maintaining their own internal trust db. And yes, I know that this is ideally how we want ARC to work; Zoho are just eager and early to the party. They were not receptive to my opinion on the flaw with their strategy.

In my client’s case, their ISP has no plans to implement ARC, so Zoho grudgingly disabled the filtering for their account.

This incident made me wonder how much stealth ARC is out there, i.e. it’s not evident that it’s being used at all, or indeed for filtering decisions, until you poke the organisation.

Ken.

From: dmarc <[email-masked]> On Behalf Of Murray S. Kucherawy
Sent: Wednesday 22 September 2021 21:30
To: IETF DMARC WG <[email-masked]>
Subject: [dmarc-ietf] Experiments

-MSK

---

From: Todd Herr <[email-masked]>
Date: Fri, 24 Sep 2021 08:36:47 -0400

Chiming in only to mention that there is a recently created IETF mailing
list dedicated to ARC - https://www.ietf.org/mailman/listinfo/arc

Discussion of ARC data and such might be appropriate there, too.

On Thu, Sep 23, 2021 at 5:30 PM Trent Adams <tadams=
[email-masked]> wrote:

>
>
> Piling onto Alex's response... we have some ARC functionality deployed and
> servicing customers.  I'm currently looking into what useful data we can
> extract and share what we've learned from the implementation (which may
> lead to some useful topics to discuss in more depth).
>
>
>
> In a related note... an early examination seems to underscore the need to
> more guidance about how to interpret ARC sets.  As Alex pointed out...
> there are some messages with way more sets than can be used to make a
> reasonable determination about the provenance of the message.  So, at the
> very least, I think we may need to develop some ancillary documents to
> support broader adoption.
>
>
>
> More as it develops,
>
> Trent
>
>
>
>
>
> *From: *dmarc <[email-masked]> on behalf of "Brotman, Alex"
> <Alex_Brotman=[email-masked]>
> *Date: *Thursday, September 23, 2021 at 3:08 PM
> *To: *"Murray S. Kucherawy" <[email-masked]>, IETF DMARC WG <
> [email-masked]>
> *Subject: *Re: [dmarc-ietf] Experiments
>
>
>
> Murray,
>
>
>

-- 

*Todd Herr * | Technical Director, Standards and Ecosystem
*e:* [email-masked]
*m:* 703.220.4153

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

---

From: Douglas Foster <[email-masked]>
Date: Fri, 24 Sep 2021 08:57:59 -0400

The Zoho situation is an interesting application of ARC.   The forwarders
are not altering the messages, so if the DMARC-enforcing domain was
configured with signatures, their messages would have passed DMARC at the
final destination.  Without the signature, they should have been blocked
already.   Apparently Zoho had encountered a lot of domains which were
DMARC-enforcing but not signing, so they were not enforcing DMARC at all.
Then they implemented ARC, so that they could trust SPF alignment if the
message was aligned before forwarding, and began enforcing DMARC at
reception.   But without ARC support at the forwarder, the sender
configuration problem persists.

It also highlights the difficulty of being a forwarder.    What to do if a
message from a DMARC-enforcing domain sends you a message, does not sign
it, and it needs to be forwarded?   If you forward anyway, the final
recipient may block the message, with or without notification, and blame
you.   You could apply the Zoho defense, and add your own ARC set, which
may or may not be recognized and trusted.   The forwarder is in a quandary,
because the final recipient (a) may ignore DMARC and want the message even
without DMARC PASS, (b) may enforce DMARC and ignore ARC, still blocking
the message and blaming you, or (c) may enforce DMARC but honor your ARC
set and allow the message because of ARC.   Without knowledge of the final
evaluator behavior, there is no correct answer.

On Fri, Sep 24, 2021 at 6:56 AM Ken O'Driscoll <ken=
[email-masked]> wrote:

>
>
> Well, I have had a deliverability related encounter with ARC in the wild,
> and can report that ARC is actively being used by Zoho.
>
>
>
> A client was using Zoho for their service desk and messages started going
> missing. The way these service desks work is that you forward say
> [email-masked] to a unique Zoho supplied email address which goes to
> your service desk queue.
>
>
>
> On investigation, it was determined that the only messages going missing
> were those originating from domains with an enforcing DMARC policy and
> non-aligned/non-existent/broken DKIM.
>
>
>
> Correspondence with Zoho’s customer service revealed that they a) have
> implemented ARC, b) expect every mailbox provider to also have implemented
> ARC, and c) are making filtering decisions on that belief. They appear to
> be maintaining their own internal trust db. And yes, I know that this is
> ideally how we want ARC to work; Zoho are just eager and early to the
> party. They were not receptive to my opinion on the flaw with their
> strategy.
>
>
>
> In my client’s case, their ISP has no plans to implement ARC, so Zoho
> grudgingly disabled the filtering for their account.
>
>
>
> This incident made me wonder how much stealth ARC is out there, i.e. it’s
> not evident that it’s being used at all, or indeed for filtering decisions,
> until you poke the organisation.
>
>
>
> Ken.
>
>
>
> *From:* dmarc <[email-masked]> *On Behalf Of *Murray S. Kucherawy
> *Sent:* Wednesday 22 September 2021 21:30

---

From: Henning Krause <[email-masked]>
Date: Fri, 24 Sep 2021 13:10:17 +0000

We've deployed ARC validation on our cloud infrastructure for a few months now, and while I can't disclose absolute numbers, I can give some percentages:

The failure rate with DMARC is about 7.5% of the mails which have a DMARC policy associated.

And with ARC we can compensate the failure in about 9.75% of these cases. 

Our service has mostly German customers and we're seeing an increasing number of ARC intermediaries, but most have very little volume. The only significant intermediaries are (in descending order of mail volume): Microsoft.com, Strato.com, google.com, then a couple of domains related to zohomail.

Kind regards,
Henning

> -----Original Message-----
> From: dmarc [mailto:[email-masked]] On Behalf Of Douglas Foster
> Sent: Freitag, 24. September 2021 14:58
> The Zoho situation is an interesting application of ARC.   The forwarders are
> not altering the messages, so if the DMARC-enforcing domain was
> It also highlights the difficulty of being a forwarder.    What to do if a message
> from a DMARC-enforcing domain sends you a message, does not sign it, and
> it needs to be forwarded?   If you forward anyway, the final recipient may
> block the message, with or without notification, and blame you.   You could
> apply the Zoho defense, and add your own ARC set, which may or may not
> be recognized and trusted.   The forwarder is in a quandary, because the final
> recipient (a) may ignore DMARC and want the message even without
> DMARC PASS, (b) may enforce DMARC and ignore ARC, still blocking the
> message and blaming you, or (c) may enforce DMARC but honor your ARC
> On Fri, Sep 24, 2021 at 6:56 AM Ken O'Driscoll
> <ken=[email-masked]
> <mailto:[email-masked]> > wrote:
> 
> 
> 
> 
> 	Well, I have had a deliverability related encounter with ARC in the
> wild, and can report that ARC is actively being used by Zoho.
> 
> 
> 
> 	A client was using Zoho for their service desk and messages started
> going missing. The way these service desks work is that you forward say
> [email-masked] <mailto:[email-masked]>  to a unique Zoho
> supplied email address which goes to your service desk queue.
> 
> 
> 
> 	On investigation, it was determined that the only messages going
> missing were those originating from domains with an enforcing DMARC policy
> and non-aligned/non-existent/broken DKIM.
> 
> 
> 
> 	Correspondence with Zoho’s customer service revealed that they a)
> have implemented ARC, b) expect every mailbox provider to also have
> implemented ARC, and c) are making filtering decisions on that belief. They
> appear to be maintaining their own internal trust db. And yes, I know that
> this is ideally how we want ARC to work; Zoho are just eager and early to the
> party. They were not receptive to my opinion on the flaw with their strategy.
> 
> 
> 
> 	This incident made me wonder how much stealth ARC is out there,
> i.e. it’s not evident that it’s being used at all, or indeed for filtering decisions,
> 	From: dmarc <[email-masked] <mailto:dmarc-
> [email-masked]> > On Behalf Of Murray S. Kucherawy
> 	To: IETF DMARC WG <[email-masked] <mailto:[email-masked]> >
> 	Is anyone in a position to comment on the ARC and PSD experiments
> and how they're progressing?  Deployment status?  Data acquired thus far?
> 
> 
> 
> 	-MSK
> 
> 
> 
> 	[email-masked] <mailto:[email-masked]>

---

From: "John Levine" <[email-masked]>
Date: 24 Sep 2021 14:59:22 -0400

It appears that Douglas Foster  <[email-masked]> said:
>-=-=-=-=-=-
>already. ....

There are plenty of senders who only use SPF and publish a DMARC policy anyway.

We all know why that's a bad idea, but that's what they do.

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: Alessandro Vesely <[email-masked]>
Date: Mon, 27 Sep 2021 10:23:10 +0200

On Fri 24/Sep/2021 14:57:59 +0200 Douglas Foster wrote:
> It also highlights the difficulty of being a forwarder.    What to do 
> if a message from a DMARC-enforcing domain sends you a message, does 
> not sign it, and it needs to be forwarded?   If you forward anyway, 
> the final recipient may block the message, with or without 
> notification, and blame you.   You could apply the Zoho defense, and 
> add your own ARC set, which may or may not be recognized and trusted.  
>   The forwarder is in a quandary, because the final recipient (a) may 
> ignore DMARC and want the message even without DMARC PASS, (b) may 
> enforce DMARC and ignore ARC, still blocking the message and blaming 
> you, or (c) may enforce DMARC but honor your ARC set and allow the 
> message because of ARC.  Without knowledge of the final evaluator 
> behavior, there is no correct answer.

There is a case (d) final receiver enforcea DMARC and ARC, but the 
forwarder is not among its ARC-trusted senders.

The simple solution if From: rewriting.  Note that forwarders should 
always rewrite the bounce address, for SPF.  Instead, rewriting From: 
can be restricted to unsigned messages from hard-policy domains.  It 
works regardless of ARC implementations.

Best
Ale
--

---

From: Douglas Foster <[email-masked]>
Date: Mon, 27 Sep 2021 06:29:10 -0400

If a domain has an enforceable DMARC policy, and the message has no
signature, then the policy interpretation would be equivalent to a "DO NOT
FORWARD" order on postal mail.

We expect that this action is probably not what the actual sender intends
or what the final recipient wants, just what the policy recommends.  The
forwarding mediator has incentives to please the final recipient, so he is
unlikely to enforce a "Do Not Forward" request even if it is
legitimately made.

Since this situation happens with some regularity, does it warrant some
commentary in the specification?

---

From: Dotzero <[email-masked]>
Date: Mon, 27 Sep 2021 10:20:20 -0400

> unlikely to enforce a "Do Not Forward" request even if it is

DMARC deals with signals from domains, not individual users (except for the
edge case of personal domains). IETF standards deal with interoperability,
not crystal balls or psychic readings attempting to interpret the wishes of
individual users. If a Sending Domain publishes a policy, the Validator,
whether an Intermediary or a Receiving Domain, has the choice of respecting
the policy expressed by the Sending Domain or alternatively, exercising a
local policy choice contrary to the Sending Domain policy request. It
really is that simple. Trying to enshrine the basis for a multitude of
potential reasons for local policy choices in an IETF standard is a
guaranteed fail.

> commentary in the specification?

The only appropriate commentary is a warning to Sending Domains which
choose to publish DMRC policy: "Be careful what you ask for. You might just
get what you ask". When people publish broken DNS records (A, MX, etc.) do
we tell others to guess the intent of the publishing domain? No, if one
sees a broken record and feels like it, they tell the domain registrant
(assuming the veil of opacity created by GDPR can be pierced) to fix their
DNS record.

Michael Hammer

---

From: "John Levine" <[email-masked]>
Date: 27 Sep 2021 15:42:48 -0400

It appears that Alessandro Vesely  <[email-masked]> said:
>The simple solution if From: rewriting.

I think you misspelled "ugly kludge" there.

>  Note that forwarders should always rewrite the bounce address, for SPF. 

Mailing lists put on their own bounce addresses so they can do bounce handling.
They've been doing that for about 40 years.  That's not a kludge, that's how
mailing lists work.

The whole point of ARC is so that lists and other forwarders *don't* have to do ugly kludges
so I don't understand the point of this discussion.

R's,
John

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 28 Sep 2021 11:14:34 +0200

> I think you misspelled "ugly kludge" there.

https://wiki.asrg.sp.am/wiki/Mitigating_DMARC_damage_to_third_party_mail#Replace_address_with_a_generic_one

> They've been doing that for about 40 years.  That's not a kludge, that's how

I agree that replacing the bounce address has a VERP logic which predates SPF.  In addition, it doesn't interfere with MUA displaying.  So, yes, it's less ugly, but it's still a kind of kludge.

By design, DMARC forced the semantics of From:.  It traded purism for efficacy.  Some ugliness has to be in the bargain too.

From: rewriting is a kludge, and it's how mailing lists work.

> so I don't understand the point of this discussion.

With ARC you have to distinguish cases (a), (b), (c), and (d).  There is no method (yet) to tell beforehand whether it's going to work at a given receiver.  Even if there was one, you should still consider the case that the subscribed address will be forwarded to yet another receiver.

Best
Ale
--

---

From: Douglas Foster <[email-masked]>
Date: Tue, 28 Sep 2021 07:04:19 -0400

Stated another way, the problem with ARC is that it requires the evaluator
to attribute a positive reputation to the forwarder, in a context where
even identifying the forwarder can be difficult.   Most email is accepted
on a much weaker criteria - the absence of negative reputation.

Mailing lists actually deserve an above-average reputation, because their
messages are pre-filtered based on identity and content before being
forwarded.   But because they preserve the author address, list messages
appear to be a random mail stream containing normal threat risks.
 From-rewriting of all list messages would allow the list to be evaluated
based on the list reputation, rather than the random reputations of the
list members.

The existing approach to From rewrite is a mess, but it is not the only one
possible.    A DMARC-compliant list would solve a lot of problems, and is
feasible, with the right type of rewrite.

Doug

On Tue, Sep 28, 2021 at 5:14 AM Alessandro Vesely <[email-masked]> wrote:

> I agree that replacing the bounce address has a VERP logic which predates
> SPF.  In addition, it doesn't interfere with MUA displaying.  So, yes, it's
> less ugly, but it's still a kind of kludge.
>
> By design, DMARC forced the semantics of From:.  It traded purism for
> efficacy.  Some ugliness has to be in the bargain too.
>
> With ARC you have to distinguish cases (a), (b), (c), and (d).  There is
> no method (yet) to tell beforehand whether it's going to work at a given
> receiver.  Even if there was one, you should still consider the case that
> the subscribed address will be forwarded to yet another receiver.
>
>
> Best
> Ale
> --
>
>
>
>
>
>
>
>
>
>
>
>
>

---

From: "John R Levine" <[email-masked]>
Date: 28 Sep 2021 08:28:20 -0400

> https://wiki.asrg.sp.am/wiki/Mitigating_DMARC_damage_to_third_party_mail#Replace_address_with_a_generic_one

Yes, I know about that list of ugly kludges, since I wrote it.

>> Mailing lists put on their own bounce addresses so they can do bounce >> handling.
>> They've been doing that for about 40 years.  That's not a kludge, that's >> how
>> mailing lists work.
>
> I agree that replacing the bounce address has a VERP logic which predates SPF.

Mailing lists were changing the bounce address long before VERP was 
invented.  It's how they work.

> From: rewriting is a kludge, and it's how mailing lists work.

No maiing list rewrote From: until AOL and Yahoo abused DMARC and people 
invented the kludge to sort of work around it.

>> The whole point of ARC is so that lists and other forwarders *don't* have 
>> to do ugly kludges so I don't understand the point of this discussion.
>
> With ARC you have to distinguish cases (a), (b), (c), and (d).

Well, you can hope, but as you know, there's no guarantees when you're 
sending mail.

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: Wed, 29 Sep 2021 13:41:56 +0200

On Tue 28/Sep/2021 13:04:19 +0200 Douglas Foster wrote:
> Stated another way, the problem with ARC is that it requires the evaluator to 
> attribute a positive reputation to the forwarder, in a context where even 
> identifying the forwarder can be difficult.

Exactly.  To use ARC you need to be a global mailbox provider; that is, have a 
perfect knowledge of mail servers worldwide.  Note that you don't need ARC or 
DMARC to stop phishing if you are in such position.

> Most email is accepted on a much weaker criteria - the absence of negative
> reputation.

That's not so reliable, because 0-day debutantes would escape that filter.

> forwarded.   But because they preserve the author address, list messages appear 
> to be a random mail stream containing normal threat risks.   From-rewriting of 
> all list messages would allow the list to be evaluated based on the list 
> reputation, rather than the random reputations of the list members.

I don't think so.  In fact, at the time being, global providers are the only 
ones who are able to maintain a reliable reputation database.  Using ARC, they 
could ascribe to the list the reputation it deserves, irrespective of From: 
rewriting.

Besides lists, many forwarders do some filtering on what they forward.  With 
20/20 global sight, ARC users can accurately reckon the reputation of the 
forwarder as well as that of the author's domain.  IMHO, maintaining reputation 
databases that way is the only good use one can make of ARC.  You can ARC-sign 
a message to enforce authentication without claiming "some responsibility" (or 
claiming less responsibility) for it.

Best
Ale
--