Re: [dmarc-ietf] ARC, DMARCbis WGLC - Issue 144 Mention of ARC in DMARCbis

[Seth Blank]

On Tue, Apr 2, 2024 at 2:18 PM Murray S. Kucherawy 
wrote:

> On Tue, Apr 2, 2024 at 9:03 AM Seth Blank  wrote:
>
>>
>> I think details about the technique to which you're alluding, especially
>>> with real world examples, anecdotes, or other data, would be really
>>> valuable to publish somewhere, be that in this document or elsewhere.  Even
>>> just a paragraph that explains what ARC brings that we didn't have before,
>>> that can be used to mitigate DMARC damage, would be a step in the right
>>> direction.
>>>
>>> The ARC usage document appears to have been parked and expired, so that
>>> advice doesn't seem to exist anywhere now.  Is the plan to revive that, now
>>> that we appear to have at least one source of experience?
>>>
>>
>> At M3AAWG a month ago, a couple of major mailboxes agreed to share their
>> experience (and success) with ARC to this list. It is apparently making a
>> significant difference for their systems. Getting that data public is still
>> slow moving.
>>
>
> That would be really interesting to see.  Since you have seen it, what's
> your view on whether such material is a viable input to this WGLC?  Should
> we wait for it?
>

I don't think it's terribly material to WGLC for dmarc-bis, I do think it's
relevant for progressing the ARC experiment after WGLC.

Seth, hatless



> -MSK, p11g
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>


-- 

Seth Blank | Chief Technology Officer
Email: s...@valimail.com


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.
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] ARC, DMARCbis WGLC - Issue 144 Mention of ARC in DMARCbis

[Murray S. Kucherawy]

On Tue, Apr 2, 2024 at 9:03 AM Seth Blank  wrote:

>
> I think details about the technique to which you're alluding, especially
>> with real world examples, anecdotes, or other data, would be really
>> valuable to publish somewhere, be that in this document or elsewhere.  Even
>> just a paragraph that explains what ARC brings that we didn't have before,
>> that can be used to mitigate DMARC damage, would be a step in the right
>> direction.
>>
>> The ARC usage document appears to have been parked and expired, so that
>> advice doesn't seem to exist anywhere now.  Is the plan to revive that, now
>> that we appear to have at least one source of experience?
>>
>
> At M3AAWG a month ago, a couple of major mailboxes agreed to share their
> experience (and success) with ARC to this list. It is apparently making a
> significant difference for their systems. Getting that data public is still
> slow moving.
>

That would be really interesting to see.  Since you have seen it, what's
your view on whether such material is a viable input to this WGLC?  Should
we wait for it?

-MSK, p11g
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Overall last-call comments on DMARC

[Murray S. Kucherawy]

On Tue, Apr 2, 2024 at 9:01 AM Alessandro Vesely  wrote:

>  By now, most mailing lists arranged to either rewrite From: or not
> break
>  DKIM signatures.  We all hope those hacks are temporary.
> >>>
> >>> What do you mean by "temporary", given the time scales that have
> already
> >>> passed since RFC 7489 saw wide deployment?  Do you envision those
> >>> techniques ending sometime soon?
> >>
> >> Yeah, the time scale is killing us.  Is ten years soon enough?
> >
> > You tell me.  You say you're hoping they're temporary, yet they've been
> > around a long time and I'm not sure that there's an alternative on the
> > table.  I'm asking you to explain.
>
> I believe alternatives are possible.  Can't say how long it's going to
> take,
> but I presume when they are available, the nasty hacks will slowly fade
> out.
>

So what are you suggesting should go in this document that's in WGLC?


> >>> If "most" mailing lists have arranged rewrites or non-mutation, and
> this
> >>> appears to be working, are there specific techniques we should
> >>> standardize here?
> >>
> >> I believe it's possible to leverage ARC so as to overcome those mailing
> >> lists hacks, for an expanding set of domains.  It is not difficult to
> >> modify ML software in order to rewrite and/or mutate on a per-user
> basis.
> >> One can obtain the same effect with existing software if it provides
> for
> >> twin lists or similar means to split users into two categories.
> >
> > This isn't consistent with your previous comment, which claimed that
> "most"
> > lists are already doing this.  Your language here is more like a
> proposal.
> > I'm having a hard time following.
>
> Oh, perhaps you asked if we should standardize the nasty hack?  IMHO, we
> shouldn't.  We didn't standardize COI either.
>

Same question.  I can't tell if you're just pontificating about a variety
of topics, or making concrete suggestions about what the -bis document
really needs to say before this WG ships it.  If the former, I suggest this
be minimized as they're likely only distractions; if the latter, I'd love
to see some proposed text.

We should standardize some proposals that make ARC work consistently for
> forwarders (including MLs) of any size and kind.
>

Do you have one to suggest?


> > What is it that you believe we should be telling industry to do?
>
> Experiment with new proposals until we find one that works?
>

Same question.


> >>> Are you suggesting we need some standard way to calculate and/or share
> a
> >>> sealer's reputation for any of this to work?
> >>
> >> Sealer's reputation is the same as domain reputation.  Good to have it,
> >> whenever it comes.
> >
> > I interpreted your earlier remark to be a claim that this stuff won't
> work
> > absent such data.
>
> A reliable reputation database will certainly make everything email work
> better.  However, ARC usage with local trust contracts, granted on a case
> by
> case basis could work even without it, methinks.
>

Do you have specific text to suggest?


> >> For ARC, I'd rather consider per-forwarder contracts.  Forwarding (of
> >> which MLs are a case) doesn't happen out of the blue.  It has to be set
> >> up. Involving the target receiver in the setup may make it trust the
> >> sender's seals, when they belong to the stream thus set up and
> >> identified.
> >
> > So, a "contract" between each mailing list and each subscriber?  What
> would
> > that mean?
>
> A contract would mean the same as COI, but involving (also) the
> subscriber's
> MBP.  Is it really you?  You sure you want to subscribe to this?  Then
> I'll
> trust the ML when it ARC-seals messages with this List-Id: destined to
> you, for
> example.
>

Have you tried this technique?  Has anyone?  Does it work?

-MSK, p11g
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARCbis WGLC - Issue 144 Mention of ARC in DMARCbis

[Emanuel Schorsch]

Three concrete use-cases where ARC is helpful:

1) SPF Downgrade
.
We didn't reach consensus for adding auth= tag to DMARC and so SPF Upgrade
remains a significant vulnerability for achieving a DMARC pass. Having the
ARC headers allows us to detect that this has occurred and respond
appropriately (reject/spam-folder the message or just downgrade the
authentication state in our system).
2) Excluding indirect mail flows from parts of Sender Requirements

/
NoAuthNoEntry. Having the ARC headers and a safe way to consistently
identify the indirect flow in a non-spoofable way allows us to not apply
requirements that don't make sense for forwarded mail (e.g. requiring SPF
or DMARC alignment)
3) Local policy for DMARC failures. For example, downgrading p=reject to
p=quarantine if ARC headers indicating indirect mail and previous alignment
are present.

On Tue, Apr 2, 2024 at 6:37 AM Murray S. Kucherawy 
wrote:

> Hi Emanuel,
>
> On Tue, Apr 2, 2024 at 1:02 AM Emanuel Schorsch 
> wrote:
>
>> Just to chime in, Gmail is using ARC and it has already provided a large
>> amount of value for the indirect flow problem. Especially, since other
>> major providers and a number of forwarders are adding ARC headers that
>> provide us useful visibility into the previous hops and allow us to make
>> more intelligent decisions. I can share that a number of escalations for
>> problems that arose out of indirect flows have been resolved by use of ARC
>> headers.
>>
>
> Can you give an example, even if only a hypothetical one?
>
> I would love to hear more detail than "Yes, it provides value."  How,
> exactly?  And have any other operators found the same?
>
> -MSK, p11g
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] RUA XML : maxOccurs="unbounded" not allowed

[Matthäus Wander]

OLIVIER HUREAU wrote on 2024-04-02 18:41:

Shouldn't we remove the maxOccurs for the error element ?


[...]


NEW
```

  
   
   
   
   
   
   
  

```


For the sake of consistency, either remove maxOccurs from each element 
under  or set maxOccurs="1" for each.


Regards,
Matt

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

Re: [dmarc-ietf] RUA XML : maxOccurs="unbounded" not allowed

[Alessandro Vesely]

On Tue 02/Apr/2024 18:41:50 +0200 OLIVIER HUREAU wrote:

Hi,

I have tried to run some measurements with the new XSD but it seems that it is 
not valid :


```
xmlschema.validators.exceptions.XMLSchemaParseError: attribute 
maxOccurs='unbounded': value must be one of [0, 1]:

```

The complex type "ReportMetadataType" has a  (see below).
However the Python library i am using refuses the XSD files as, according to 
W3, macOccurs unbounded are not accepted in all :


```
Schema Component Constraint: All Group Limited
When a model group has {compositor} all, then all of the following must be true:
1 It appears only as the value of one or both of the following properties:
1.1 the {model group} property of a model group definition.
1.2 the {term} property of a particle with {max occurs}=1which is part of a 
pair which constitutes the {content type} of a complex type definition.
2 The {max occurs} of all the particles in the {particles} of the group must be 
0 or 1.

```
https://www.w3.org/TR/xmlschema-1/#cos-all-limited 



Shouldn't we remove the maxOccurs for the error element ?



Alternatively, if we want it unbounded, move the error element outside 
.  For example as an optional, self standing element of 
feedback, between  and .



Best
Ale
--




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

[dmarc-ietf] RUA XML : maxOccurs="unbounded" not allowed

[OLIVIER HUREAU]

Hi, 

I have tried to run some measurements with the new XSD but it seems that it is 
not valid : 

``` 
xmlschema.validators.exceptions.XMLSchemaParseError: attribute 
maxOccurs='unbounded': value must be one of [0, 1]: 
``` 

The complex type "ReportMetadataType" has a  (see below). 
However the Python library i am using refuses the XSD files as, according to 
W3, macOccurs unbounded are not accepted in all : 

``` 
Schema Component Constraint: All Group Limited 
When a model group has {compositor} all, then all of the following must be 
true: 
1 It appears only as the value of one or both of the following properties: 
1.1 the {model group} property of a model group definition. 
1.2 the {term} property of a particle with {max occurs}=1which is part of a 
pair which constitutes the {content type} of a complex type definition. 
2 The {max occurs} of all the particles in the {particles} of the group must be 
0 or 1. 
``` 
[ https://www.w3.org/TR/xmlschema-1/#cos-all-limited | 
https://www.w3.org/TR/xmlschema-1/#cos-all-limited ] [ 
https://www.w3.org/TR/xmlschema-1/#cos-all-limited ] 

Shouldn't we remove the maxOccurs for the error element ? 


-- 


OLD 
``` 
 
 
 
 
 
 
 
 
 
 
``` 



NEW 
``` 
 
 
 
 
 
 
 
 
 
 
``` 





- 
Olivier HUREAU 
PhD Student 
Laboratoire Informatique Grenoble - UGA - Drakkar 
[ https://hureau.com/ | hureau.com ] 
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] ARC, DMARCbis WGLC - Issue 144 Mention of ARC in DMARCbis

[Seth Blank]

On Tue, Apr 2, 2024 at 11:58 AM Murray S. Kucherawy 
wrote:

> On Tue, Apr 2, 2024 at 8:49 AM John Levine  wrote:
>
>> It appears that Murray S. Kucherawy   said:
>> >Can you give an example, even if only a hypothetical one?
>>
>> I'm not Emmanuel but people at large mail systems have told me that
>> the biggest value of ARC is to deal with mailing lists that do lousy
>> spam filtering. Lists often let anything through that has the address
>> of a subscriber on the From: line. Mail systems see legit lists that
>> gush spam when some bot starts sending mail to the list with fake
>> subscriber addresses, because the bot herder is using address pairs
>> from stolen address books.
>>
>> While we all know the reasons that you don't want to enforce DMARC on
>> the mail coming out of a mailing list, it makes a lot more sense to
>> enforce it on mail going into a list. You can use ARC to look back and
>> see if the mail was aligned on the way in and if not treat it as spam.
>>
>
> I think details about the technique to which you're alluding, especially
> with real world examples, anecdotes, or other data, would be really
> valuable to publish somewhere, be that in this document or elsewhere.  Even
> just a paragraph that explains what ARC brings that we didn't have before,
> that can be used to mitigate DMARC damage, would be a step in the right
> direction.
>
> The ARC usage document appears to have been parked and expired, so that
> advice doesn't seem to exist anywhere now.  Is the plan to revive that, now
> that we appear to have at least one source of experience?
>

At M3AAWG a month ago, a couple of major mailboxes agreed to share their
experience (and success) with ARC to this list. It is apparently making a
significant difference for their systems. Getting that data public is still
slow moving.



>
> -MSK, p11g
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>


-- 

Seth Blank | Chief Technology Officer
Email: s...@valimail.com


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.
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Overall last-call comments on DMARC

[Alessandro Vesely]

On Tue 02/Apr/2024 15:35:05 +0200 Murray S. Kucherawy wrote:

On Tue, Apr 2, 2024 at 3:01 AM Alessandro Vesely  wrote:

By now, most mailing lists arranged to either rewrite From: or not break 
DKIM signatures.  We all hope those hacks are temporary.


What do you mean by "temporary", given the time scales that have already 
passed since RFC 7489 saw wide deployment?  Do you envision those 
techniques ending sometime soon?


Yeah, the time scale is killing us.  Is ten years soon enough?


You tell me.  You say you're hoping they're temporary, yet they've been 
around a long time and I'm not sure that there's an alternative on the 
table.  I'm asking you to explain.



I believe alternatives are possible.  Can't say how long it's going to take, 
but I presume when they are available, the nasty hacks will slowly fade out.



If "most" mailing lists have arranged rewrites or non-mutation, and this 
appears to be working, are there specific techniques we should 
standardize here?


I believe it's possible to leverage ARC so as to overcome those mailing 
lists hacks, for an expanding set of domains.  It is not difficult to 
modify ML software in order to rewrite and/or mutate on a per-user basis. 
One can obtain the same effect with existing software if it provides for 
twin lists or similar means to split users into two categories. >
This isn't consistent with your previous comment, which claimed that "most" 
lists are already doing this.  Your language here is more like a proposal. 
I'm having a hard time following.



Oh, perhaps you asked if we should standardize the nasty hack?  IMHO, we 
shouldn't.  We didn't standardize COI either.


We should standardize some proposals that make ARC work consistently for 
forwarders (including MLs) of any size and kind.




What is it that you believe we should be telling industry to do?



Experiment with new proposals until we find one that works?


Are you suggesting we need some standard way to calculate and/or share a 
sealer's reputation for any of this to work?


Sealer's reputation is the same as domain reputation.  Good to have it, 
whenever it comes.


I interpreted your earlier remark to be a claim that this stuff won't work 
absent such data.



A reliable reputation database will certainly make everything email work 
better.  However, ARC usage with local trust contracts, granted on a case by 
case basis could work even without it, methinks.



For ARC, I'd rather consider per-forwarder contracts.  Forwarding (of 
which MLs are a case) doesn't happen out of the blue.  It has to be set 
up. Involving the target receiver in the setup may make it trust the 
sender's seals, when they belong to the stream thus set up and 
identified.


So, a "contract" between each mailing list and each subscriber?  What would 
that mean?



A contract would mean the same as COI, but involving (also) the subscriber's 
MBP.  Is it really you?  You sure you want to subscribe to this?  Then I'll 
trust the ML when it ARC-seals messages with this List-Id: destined to you, for 
example.



Best
Ale
--



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

Re: [dmarc-ietf] ARC, DMARCbis WGLC - Issue 144 Mention of ARC in DMARCbis

[Murray S. Kucherawy]

On Tue, Apr 2, 2024 at 8:49 AM John Levine  wrote:

> It appears that Murray S. Kucherawy   said:
> >Can you give an example, even if only a hypothetical one?
>
> I'm not Emmanuel but people at large mail systems have told me that
> the biggest value of ARC is to deal with mailing lists that do lousy
> spam filtering. Lists often let anything through that has the address
> of a subscriber on the From: line. Mail systems see legit lists that
> gush spam when some bot starts sending mail to the list with fake
> subscriber addresses, because the bot herder is using address pairs
> from stolen address books.
>
> While we all know the reasons that you don't want to enforce DMARC on
> the mail coming out of a mailing list, it makes a lot more sense to
> enforce it on mail going into a list. You can use ARC to look back and
> see if the mail was aligned on the way in and if not treat it as spam.
>

I think details about the technique to which you're alluding, especially
with real world examples, anecdotes, or other data, would be really
valuable to publish somewhere, be that in this document or elsewhere.  Even
just a paragraph that explains what ARC brings that we didn't have before,
that can be used to mitigate DMARC damage, would be a step in the right
direction.

The ARC usage document appears to have been parked and expired, so that
advice doesn't seem to exist anywhere now.  Is the plan to revive that, now
that we appear to have at least one source of experience?

-MSK, p11g
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] ARC, DMARCbis WGLC - Issue 144 Mention of ARC in DMARCbis

[John Levine]

It appears that Murray S. Kucherawy   said:
>Can you give an example, even if only a hypothetical one?

I'm not Emmanuel but people at large mail systems have told me that
the biggest value of ARC is to deal with mailing lists that do lousy
spam filtering. Lists often let anything through that has the address
of a subscriber on the From: line. Mail systems see legit lists that
gush spam when some bot starts sending mail to the list with fake
subscriber addresses, because the bot herder is using address pairs
from stolen address books.

While we all know the reasons that you don't want to enforce DMARC on
the mail coming out of a mailing list, it makes a lot more sense to
enforce it on mail going into a list. You can use ARC to look back and
see if the mail was aligned on the way in and if not treat it as spam.

R"s,
JOhn

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

Re: [dmarc-ietf] DMARCbis WGLC - Issue 144 Mention of ARC in DMARCbis

[Murray S. Kucherawy]

Hi Emanuel,

On Tue, Apr 2, 2024 at 1:02 AM Emanuel Schorsch 
wrote:

> Just to chime in, Gmail is using ARC and it has already provided a large
> amount of value for the indirect flow problem. Especially, since other
> major providers and a number of forwarders are adding ARC headers that
> provide us useful visibility into the previous hops and allow us to make
> more intelligent decisions. I can share that a number of escalations for
> problems that arose out of indirect flows have been resolved by use of ARC
> headers.
>

Can you give an example, even if only a hypothetical one?

I would love to hear more detail than "Yes, it provides value."  How,
exactly?  And have any other operators found the same?

-MSK, p11g
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Overall last-call comments on DMARC

[Murray S. Kucherawy]

On Tue, Apr 2, 2024 at 3:01 AM Alessandro Vesely  wrote:

> >> By now, most mailing lists arranged to either rewrite From: or not
> break
> >> DKIM signatures.  We all hope those hacks are temporary. >
> >
> > What do you mean by "temporary", given the time scales that have already
> > passed since RFC 7489 saw wide deployment?  Do you envision those
> > techniques ending sometime soon?
>
> Yeah, the time scale is killing us.  Is ten years soon enough?
>

You tell me.  You say you're hoping they're temporary, yet they've been
around a long time and I'm not sure that there's an alternative on the
table.  I'm asking you to explain.


> > If "most" mailing lists have arranged rewrites or non-mutation, and this
> > appears to be working, are there specific techniques we should
> standardize
> > here?
>
> I believe it's possible to leverage ARC so as to overcome those mailing
> lists
> hacks, for an expanding set of domains.  It is not difficult to modify ML
> software in order to rewrite and/or mutate on a per-user basis.  One can
> obtain
> the same effect with existing software if it provides for twin lists or
> similar
> means to split users into two categories.
>

This isn't consistent with your previous comment, which claimed that "most"
lists are already doing this.  Your language here is more like a proposal.
I'm having a hard time following.

What is it that you believe we should be telling industry to do?

> Are you suggesting we need some standard way to calculate and/or share a
> > sealer's reputation for any of this to work?
>
> Sealer's reputation is the same as domain reputation.  Good to have it,
> whenever it comes.
>

I interpreted your earlier remark to be a claim that this stuff won't work
absent such data.


> For ARC, I'd rather consider per-forwarder contracts.  Forwarding (of
> which MLs
> are a case) doesn't happen out of the blue.  It has to be set up.
> Involving
> the target receiver in the setup may make it trust the sender's seals,
> when
> they belong to the stream thus set up and identified.
>

So, a "contract" between each mailing list and each subscriber?  What would
that mean?

-MSK, p11g
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] ARC, was WGLC editorial review of draft-ietf-dmarc-dmarcbis-30

[Alessandro Vesely]

On Mon 01/Apr/2024 22:01:22 +0200 Murray S. Kucherawy wrote:

On Mon, Apr 1, 2024 at 11:33 AM Todd Herr 
 wrote:


[...]

Should DMARC-bis reference ARC? I don't know; can it? What I mean by that 
is that some of us have an interest in DMARC-bis being published as 
Standards track, and ARC is Experimental, and I don't fully understand the 
rules regarding down-referencing (is that the right term?).


This would be fine:

"One possible mitigation to problem X is [ARC], which provides for a 
mechanism to demonstrate 'chain-of-custody' of a message.  However, use of 
ARC is nascent, as is industry experience with it in connection with DMARC."



I'd insert a third paragraph in section 5.8, Policy Enforcement Considerations, 
after the 2nd paragraph, which explains not to blindly reject.  Let me try and 
expand the text above:


One possible source of alternative knowledge is [ARC], which provides for
a mechanism to demonstrate 'chain-of-custody' of a message.  However, use
of ARC requires extra care in understanding its implications, as industry
experience with it in connection with DMARC is still being gathered.


Best
Ale
--





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

Re: [dmarc-ietf] DMARCbis WGLC - Issue 144 Mention of ARC in DMARCbis

[Alessandro Vesely]

On Tue 02/Apr/2024 10:11:08 +0200 Emanuel Schorsch wrote:

Just to add some specifics, since August of 2023 we've gone from seeing
~100 ARC sealers of meaningful volume to over 300 as of yesterday. It is
extremely important in our experience to have standard ways of identifying
indirect flows. ListId headers and ReceivedHeaders are the bare minimum for
MailingLists today, but those are both easily spoofable and ARC provides a
much safer approach to standardizing that indirect flow identification
problem.



It would be desirable to have a means to set up indirect mail flows so as to 
make ARC sealers trusted even when they are low-volume senders.  It would also 
be nice to know, for DMARC-triggered bounces, whether any ARC seal also failed 
to verify rather than not being trusted.  In the latter case, if a procedure 
exists to register ARC sealers, the 5xx response would be a good place to 
advertise it.



Best
Ale
--



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

Re: [dmarc-ietf] Standards Track? Yes or No.

[Alessandro Vesely]

On Tue 02/Apr/2024 07:13:16 +0200 Douglas Foster wrote:
Standards track?   Not until we fix the failure inherited from RFC 7489: the 
untutored evaluator who does not know how to use DMARC results wisely.



Doing it all-at-once would expand the time scale unbearably.  In addition, we'd 
need to timely communicate the progress in some other unofficial way, lest the 
final outcome go unnoticed.



Best
Ale
--



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

Re: [dmarc-ietf] Overall last-call comments on DMARC

[Alessandro Vesely]

On Mon 01/Apr/2024 16:35:28 +0200 Murray S. Kucherawy wrote:

On Mon, Apr 1, 2024 at 4:44 AM Alessandro Vesely  wrote:

* Mailing lists — Mailing list operators, including ietf.org, have had 
to implement rewriting of From addresses such as u...@example.com 
becomes user=40example@dmarc.ietf.org when a p=strict or 
p=quarantine policy is in place. This works to some extent for IETF, but 
there is an enormous number of mailing list operators, each of whom 
would need to implement address rewriting. While address rewriting is 
not the recommended solution, it is widely used because of the 
widespread inappropriate use described above. >>
By now, most mailing lists arranged to either rewrite From: or not break 
DKIM signatures.  We all hope those hacks are temporary. >
What do you mean by "temporary", given the time scales that have already 
passed since RFC 7489 saw wide deployment?  Do you envision those 
techniques ending sometime soon?



Yeah, the time scale is killing us.  Is ten years soon enough?


If "most" mailing lists have arranged rewrites or non-mutation, and this 
appears to be working, are there specific techniques we should standardize 
here?



I believe it's possible to leverage ARC so as to overcome those mailing lists 
hacks, for an expanding set of domains.  It is not difficult to modify ML 
software in order to rewrite and/or mutate on a per-user basis.  One can obtain 
the same effect with existing software if it provides for twin lists or similar 
means to split users into two categories.



ARC provides a protocol whereby a mailing list can certify its behavior to 
an end receiver. Unfortunately, we are still missing a protocol whereby 
trusting an ARC sealer can be established by a receiver for each mail 
stream.  We are halfway across the ford. >

Are you suggesting we need some standard way to calculate and/or share a
sealer's reputation for any of this to work?



Sealer's reputation is the same as domain reputation.  Good to have it, 
whenever it comes.


For ARC, I'd rather consider per-forwarder contracts.  Forwarding (of which MLs 
are a case) doesn't happen out of the blue.  It has to be set up.  Involving 
the target receiver in the setup may make it trust the sender's seals, when 
they belong to the stream thus set up and identified.



Best
Ale
--




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

Re: [dmarc-ietf] DMARCbis WGLC - Issue 144 Mention of ARC in DMARCbis

[Emanuel Schorsch]

Just to add some specifics, since August of 2023 we've gone from seeing
~100 ARC sealers of meaningful volume to over 300 as of yesterday. It is
extremely important in our experience to have standard ways of identifying
indirect flows. ListId headers and ReceivedHeaders are the bare minimum for
MailingLists today, but those are both easily spoofable and ARC provides a
much safer approach to standardizing that indirect flow identification
problem.

On Tue, Apr 2, 2024 at 1:02 AM Emanuel Schorsch 
wrote:

> Just to chime in, Gmail is using ARC and it has already provided a large
> amount of value for the indirect flow problem. Especially, since other
> major providers and a number of forwarders are adding ARC headers that
> provide us useful visibility into the previous hops and allow us to make
> more intelligent decisions. I can share that a number of escalations for
> problems that arose out of indirect flows have been resolved by use of ARC
> headers.
>
> I would love to see more mailingLists add ARC headers. But as stands today
> it is already providing a reasonably large amount of value.
>
> On Mon, Apr 1, 2024 at 6:48 PM Murray S. Kucherawy 
> wrote:
>
>> On Mon, Apr 1, 2024 at 4:05 PM John Levine  wrote:
>>
>>> >"One possible mitigation to problem X is [ARC], which provides for a
>>> >mechanism to demonstrate 'chain-of-custody' of a message. However, use
>>> of
>>> >ARC is nascent, as is industry experience with it in connection with
>>> DMARC."
>>>
>>> Generally OK but nascent seems wrong for something that was published
>>> five
>>> years ago.  How about "ARC has found limited acceptance in the industy so
>>> it is unclear how much help it will provide in practice."
>>>
>>
>> Sure.  I used "nascent" because I don't feel like we have seen even basic
>> statements about how useful it's been in solving the indirect flows
>> problem, at scale or otherwise, so it's nascent in the same sense that it
>> is not well-established.
>>
>> -MSK, p11g
>> ___
>> dmarc mailing list
>> dmarc@ietf.org
>> https://www.ietf.org/mailman/listinfo/dmarc
>>
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARCbis WGLC - Issue 144 Mention of ARC in DMARCbis

[Emanuel Schorsch]

Just to chime in, Gmail is using ARC and it has already provided a large
amount of value for the indirect flow problem. Especially, since other
major providers and a number of forwarders are adding ARC headers that
provide us useful visibility into the previous hops and allow us to make
more intelligent decisions. I can share that a number of escalations for
problems that arose out of indirect flows have been resolved by use of ARC
headers.

I would love to see more mailingLists add ARC headers. But as stands today
it is already providing a reasonably large amount of value.

On Mon, Apr 1, 2024 at 6:48 PM Murray S. Kucherawy 
wrote:

> On Mon, Apr 1, 2024 at 4:05 PM John Levine  wrote:
>
>> >"One possible mitigation to problem X is [ARC], which provides for a
>> >mechanism to demonstrate 'chain-of-custody' of a message. However, use of
>> >ARC is nascent, as is industry experience with it in connection with
>> DMARC."
>>
>> Generally OK but nascent seems wrong for something that was published five
>> years ago.  How about "ARC has found limited acceptance in the industy so
>> it is unclear how much help it will provide in practice."
>>
>
> Sure.  I used "nascent" because I don't feel like we have seen even basic
> statements about how useful it's been in solving the indirect flows
> problem, at scale or otherwise, so it's nascent in the same sense that it
> is not well-established.
>
> -MSK, p11g
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc