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
<https://www.valimail.com/blog/how-an-spf-upgrade-attack-spoofed-googles-blue-checkmark/>.
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
<https://blog.google/products/gmail/gmail-security-authentication-spam-protection/>
/
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] 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

Re: [dmarc-ietf] DMARCbis way forward: Do we need our session at IETF 118

[Emanuel Schorsch]

>
> As to why, I don't think there's a valid use case and the proponents for
> this haven't really thought it through.  As an example, someone (I don't
> recall who) cited the issue of domain owners that publish SPF, but can't be
> bothered to set up DKIM.  The implication is that this minimum effort
> domain owner will read DMARCbis when it comes out and decide to update
> their records as a result with the new tag.  I don't think that's very
> realistic.
>
> So who would use this tag then?
>
> It would have to be a domain owner which publishes an SPF record that
> enables spoofing their domain, understands SPF and DMARC well enough to
> know that is a concern for DMARC and yet simultaneously doesn't know how to
> fix their SPF record and does know about this new tag.
>
> I don't think that person exists.  At best this new tag is some kind of
> security theater.
>

Thanks for that clarification! I think I can clear up what the specific use
case is. It's to deal with SPF Upgrade. Assume we have a domain, `
business.com`, that has properly set up SPF and DKIM and uses a shared
provider and so includes the relevant provider IPs in their SPF record.
They have a DMARC p=reject policy. But, unfortunately, the shared provider
they use is vulnerable to SPF upgrade and so there have been successful
upgrades allowing a spammer / phisher to achieve a `business.com` SPF pass.
Notably, this does not allow the spammer to achieve a `business.com` DKIM
pass. Today, this will be a DMARC pass (because of the SPF), and it is not
always so easy for downstream receivers to know there has been an upgrade.

Take the above example, and imagine we've added an `auth=dkim` tag option. `
business.com` then adds it to their DMARC record to protect their domain.
Now, when a receiver gets the upgraded message they see it is a DMARC fail
and can reject the message. This protects the `business.com` domain from
impersonation in a way that is not possible today without `business.com`
either removing SPF or leaving their shared provider (the only ways to "fix
their SPF record"), both a much larger change. Does that make more sense as
a legitimate use case?
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARCbis way forward: Do we need our session at IETF 118

[Emanuel Schorsch]

>
> >There's the counterargument "so don't publish SPF" but it's on so many
> checklists
> >that even though that would be a fine idea, it's not practical.
>
> Diving into the SPF angle, if someone has a 'legitimate' mail source that
> also sends spoofed mail for them, they can prefix the relevant mechanism
> with '?' so it produces a neutral rather than a pass result.  DMARC will
> ignore it then.  Still solvable in SPF with no protocol change.
>
> These sources are effectively open relays (not literally, but
> practically).  This isn't a problem that should be solved by a protocol
> change in DMARC.
>

I too had thought there was consensus on this issue. I think in this case
it is appropriate for a protocol change. Senders today do not currently
have a way to express "ignore my SPF when evaluating DMARC". Adding that to
the protocol is necessary to give them that choice. We have seen hundreds
of senders affected by this issue and it is not acceptable for them to turn
off SPF because there are a variety of receivers out there with varying
requirements and turning off SPF entirely might have a negative impact. It
is more than acceptable for them to say: ignore SPF from the perspective of
DMARC.
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Eliminating From Munging from this list

[Emanuel Schorsch]

Having negotiations between senders, evaluators and lists sounds difficult.
I agree the dream would be to have at least a semi-automated solution which
works. I'd be interested to hear what you think of the following rough idea
(with the assumption that most lists today are currently doing FromMunging
on p=reject domains):

   - By default FromMunging remains the practice without special
   information.
   - MailingLists add ARC Headers and an additional header for what the
   unmunged FromHeader was (with some agreed on standard, e.g. Wei's
   proposal
   
<https://datatracker.ietf.org/doc/html/draft-chuang-mailing-list-modifications-00>
to
   use `Prior-From`).

This gives the information needed to evaluators to undo the fromMunging on
their end. Evaluators can check the original authentication in case the
list does not enforce authentication checks. More importantly, evaluators
can undo the fromMunging and restore the original header within the
evaluators system. This can be based on an explicit system (user manually
adds a setting that this list is trusted), or an implicit system (evaluator
sees that the list is trustworthy in general, or that is implicitly trusted
by the specific recipient).

This would place a burden on MailingLists (to add Arc headers and original
FromHeader) and would place a burden on evaluators (to have a refined
evaluation method with a nuanced understanding of "trust" in lists). It
seems if both parties showed interest it would be a tractable solution. A
nice aspect of this solution is that I don't believe these changes would
break non-participants, and gradual adoption by individual lists /
evaluators would show benefits.

Emanuel Schorsch

On Sun, Jul 16, 2023 at 1:51 PM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:

> As long as the unsympathetic evaluator produces a reject or bounce, the
> automatic digest approach will work well.   if digest mode failover is
> implemented as an operator function, it could be implemented quickly
> without software changes .   Automating the process seems like a minor
> undertaking as well.   If the evaluator does silent discard, your approach
> depends on the evaluator noting that messages are missing.
>
> To get out of digest mode, the user still needs to negotiate with his
> evaluator.   You are despondent on that point, I am more hopeful,
> especially for this particular list's participants.   For the negotiation
> to be successful, I think the user will need the information I discussed,
> including:   a commitment of 100% sender authentication prior to
> forwarding, a definition of how the evaluator can identify list traffic,
> and clarity about what content filtering is or is not done before
> forwarding.   We don't want the list to be blacklisted simply because the
> evaluator has stricter content filtering than the list provides.
>
> Both your approach and mine will isolate the problem to unsympathetic
> evaluators and their unfortunate users.   Both approaches know that we must
> either modify the evaluator's filtering rules or live within those rules.
>  Neither of these two approaches requires asking senders to lower their
> security posture from p=reject to p=none., and both eliminate From munging,
> which is a big win.
>
> Doug Foster
>
>
> On Sun, Jul 16, 2023 at 9:25 AM Baptiste Carvello <
> devel2...@baptiste-carvello.net> wrote:
>
>> Hi,
>>
>> Le 15/07/2023 à 12:22, Douglas Foster a écrit :
>> > [...]
>> > Track 2: Exception Request
>> > [...]
>> > Track 2 benefits:
>> > [...]
>> > - Elimination of From munging is potentially available to all
>> > participants, even those from p=reject domains
>>
>> This important word here is "potentially". In practice, only an
>> insignificant part of this potential can be achieved, because your plan
>> heavily relies on non-automatable human work, and on end users being
>> able to weight into their providers' policies.
>>
>> Thus for all practical purposes, "conditional munging" is equivalent to
>> plain munging.
>>
>> Therefore I propose Track 3:
>>
>> 1) We undo existing munging.
>>
>> 2) We inform end users that, if they do not receive messages from
>> certain senders (especially those senders whose addresses were
>> previously munged), they can regain them by switching their subscription
>> mode to "digests", at least temporarily while their mailbox provider
>> fixes their DMARC handling.
>>
>> 3) Whenever we get bounces, we configure our software to forcibly switch
>> the offending users (I mean the receivers) to "digests". We inform the
>> impacted users that they can try resetting their sub

Re: [dmarc-ietf] easier DKIM, DMARC2 & SPF Dependency Removal

[Emanuel Schorsch]

On Wed, Jun 28, 2023 at 5:50 PM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:

> We are talking about SPF AND DKIM because of the problems with DKIM
> replay.   Can someone summarize the state of the DKIM update options that
> have been ruled in or ruled out?
>

I'll clarify how I view SPF AND DKIM in relation to DKIM Replay. Let's use
bob.com as the domain:

   - If DK=bob.com and SPF=bob.com then NOT dkim replay.
   - If DK=bob.com and SPF!=bob.com then MAYBE dkim replay (of course
   probability of dkim replay varies widely, and could still be 0 for this
   particular SPF)
   - If DK=bob.com and SPF!=bob.com and DMARC policy is SPF AND DKIM then
   LIKELY dkim replay if seen in large volumes.

So the value of that DMARC policy for DKIM Replay is that bob.com can be
better protected against heavy replays because they have a way to say "I've
checked all my direct flows have SPF AND DK aligned. If you see mail with a
different SPF you can be sure it's an indirect flow and be more aggressive
about quota limiting large volumes."

To be clear, that would be a benefit for protecting aligned domains that
are replayed, but I'm NOT suggesting this is enough benefit to allow users
to set SPF AND DKIM for a DMARC auth policy. I agree with others that it's
a footgun, and it would be better to convey this information in some other
way.
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] easier DKIM, DMARC2 & SPF Dependency Removal

[Emanuel Schorsch]

>
> > It would be a way for senders to say "yes I checked that all my DKIM
> > signatures are working and aligned, I don't need you to look at SPF and
> > don't want to have the risk of SPF Upgrades.
>
> So why do you publish an SPF record?  Presumably so someone will accept
> your mail who wouldn't otherwise, except you just said they shouldn't.
> Still not making sense to me.
>

DKIM Replay is still an issue. If you don't publish any SPF record then
your mail will look fairly similar to replay attacks. In this case the SPF
isn't helping recipients accept mail that has a broken DKIM, it's helping
recipients additionally reject/spam-folder replayed mail which will
according to the spec have a DMARC pass.

But putting aside DKIM Replay I think most senders would still want to
publish an SPF record since SPF has been around for a while and many
reputation systems use it as one of the factors. You just wouldn't be
publishing an SPF record to help from a DMARC perspective.
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] easier DKIM, DMARC2 & SPF Dependency Removal

[Emanuel Schorsch]

>
> > confused users misusing that option. I would support allowing the
> following
> > options for the auth tag:
> >   "auth=dkim|spf (default value: same as current state), auth=dkim,
> auth=spf"
>
> The idea is that auth=dkim means you'd publish SPF records but hope people
> will ignore them, or vice versa for auth=dkim?  I still don't get it.
>

My understanding is that if `auth=dkim` then SPF would be ignored from the
perspective of DMARC. So  if a receiver sees DKIM is not DMARC aligned and
only SPF is DMARC aligned then it would still be treated as a DMARC fail.

It would be a way for senders to say "yes I checked that all my DKIM
signatures are working and aligned, I don't need you to look at SPF and
don't want to have the risk of SPF Upgrades. I will still keep an updated
SPF record, but if you see a message that's only SPF aligned then don't
consider that a DMARC pass."
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] easier DKIM, DMARC2 & SPF Dependency Removal

[Emanuel Schorsch]

On Thu, Jun 22, 2023 at 7:18 PM John Levine  wrote:

> It appears that Emil Gustafsson   said:
> >I don't know if there is a better way to encode that, but I'm supportive
> of
> >making a change that that would allow domains to tell us (gmail) that they
> >prefer us to require both dkim and spf for DMARC evaluation (or whatever
> >combination of DKIM and SPF they desire).
>
> I really don't understand what problem this solves. More likely people
> will see blog posts telling them auth=dkim+spf is "more secure",
> they'll add that without understanding what it means, and all that
> will happen is that more of their legit mail will disappear.
>
> If you're worried about DKIM replay attacks, let's fix that rather
> than trying to use SPF, which as we know has all sorts of problems of
> its own, as a band-aid.
>
> R's,
> John
>

I agree with John's point that dkim+spf doesn't make sense in the context
of strict DMARC enforcement (I think it provides value for p=none domains
but it's not worth that complexity). If we leave out `dkim+spf` as an
option then we can still solve >90% of the problem at hand without having
confused users misusing that option. I would support allowing the following
options for the auth tag:
   "auth=dkim|spf (default value: same as current state), auth=dkim,
auth=spf"
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] The auth= tag, was DMARC2 & SPF Dependency Removal

[Emanuel Schorsch]

On Wed, Jun 21, 2023 at 1:59 AM Alessandro Vesely  wrote:

> After sleeping on it, I think the new tag could also specify DKIM /and/
> SPF,
> besides or and one only, for domains that want that extra security.
> Possible
> values, for example, auth=dkim|spf (default value), auth=dkim+spf,
> auth=dkim,
> auth=spf.
>

+1 to the spirit, but I think the meaning needs to be clarified. It adds
value to allow domains that have control of the SPF to indicate that
receivers should expect SPF and DKIM to both be DMARC aligned in the direct
mail case. This provides a very useful signal to apply DKIM Replay
mitigations if that's not the case.

But if the policy is also p=reject that would be essentially saying "this
mail should never be forwarded". That seems unreasonable, but saying DKIM
needs to be aligned for DMARC to pass, and if SPF isn't aligned then
consider the message a potential DKIM replay case. Though I don't know if
that indicator belongs in the auth tag, or would be better as a separate
parameter.
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Add MLS/MLM subscription/submissions controls to DMARCbis

[Emanuel Schorsch]

I want to ask about the "hollow victory" aspect and what would turn it into
a more meaningful victory. If fromHeader rewriting is the damage we want to
avoid it seems there's two options:
1) Have the mailingList make a decision based on what they know about the
evaluator. This would need some mechanism for evaluators to indicate what
trust techniques they accept.
2) Have the mailingList rewrite the fromHeader but store the original
fromHeader and propagate the necessary trust information so that downstream
evaluators can undo the rewriting.

Given that currently many mailingList do fromHeader rewriting it seems that
#2 would allow gradual adoption and flexibility for experimentation over
time to see what trust methods work and allow downstream evaluators to make
personalized decisions depending on the recipients trust preferences.

What are your thoughts? What would be needed for that to result in a
non-hollow victory?


On Sun, Apr 30, 2023, 9:54 PM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:

> Everything depends on an evaluator who trusts the alternate authentication
> protocol.   We have at least three trust techniques:
> - local policy at evaluator
> - ARC set trusted by evaluator
> - ATPS trusted by evaluator.
>
> Until the list knows that the evaluator will accept the credentials, he
> has to assume that rewrite is necessary to avoid message blocks,
> unsubscribes, and possibly blacklisting
>
> No such feedback exists at present, so even though ARC has some
> acceptance, it is a hollow victory.
>
> DF
>
>
> On Sun, Apr 30, 2023, 8:05 PM Hector Santos  wrote:
>
>>
>>
>> On Apr 29, 2023, at 4:42 PM, Douglas Foster <
>> dougfoster.emailstanda...@gmail.com> wrote:
>>
>> ...
>>
>> But I need to clarify whether I understand your point.   What I am
>> hearing is:
>>
>>- For the short term, mailing lists should refuse postings from
>>DMARC-enforcing domains.   That position can be relaxed only if all
>>participating domains have agreed to ignore DMARC Fail for messages from
>>the list  (Ale floated some ideas about that approach.)
>>- For the longer term, we need a non-DKIM method for delegating
>>rights to a third party.
>>
>>
>> Ideally, the goal is to eliminate “From Rewrite” to return to the “good
>> ol’ days.”  So the first time is to recognize having subscription and
>> submissions controls is a natural consideration for the DKIM Policy
>> "Protocol Complete” model. If the MLS supports the protocol, it would
>> consider this method more so than a destruction method that tear down
>> security.  This will also pass the buck back to the domain owner to deal
>> with its user’s needs or not.
>>
>> You talk about "incomplete protocol" as if this is a commonly understood
>> and accepted term.  I interpret it to mean a third-party authentication
>> method other than DKIM.  DKIM does serve for third-party authentication
>> where it has been embraced and deployed.   So the issue is that it has not
>> been practical for many situations and we do need another option.
>>
>>
>> Protocol complete is a client/server protocol negotiation concept.  It
>> basically means the “State Machine”, the conversation between the client
>> and server is well-defined. No Loop Holes Very key concept in protocol
>> design.
>>
>> In terms of DKIM Signing Practices, you can read "Requirements for a
>> DomainKeys Identified Mail (DKIM) Signing Practices Protocol https
>> ://www.rfc-editor.org/rfc/rfc5016.txt
>>  for its definition.
>>
>> DKIM Signing Complete: a practice where the dtomain holder assert
>> that all legitimate mail will be sent with a valid first party signature.
>>
>> But I believe it is not Protocol Complete and to achieve this with DKIM
>> Policy Modeling, you have to cover the other signing scenarios which
>> includes 3rd party signing scenarios.
>>
>> ATPS is the best we got and it works. You don’t have to worry, You are
>> using gmail.com. Relaxed policy. Minimal security. ietf.org Rewrite
>> destroys my isdg.net domain security even though I have ietf.org
>> authorized as an ATPS signer.
>>
>> It should honor policy and reject my submissions. Idea. Add the option to
>> the subscription. If you don’t care, let it rewrite to join or use another
>> unsecured address.
>>
>> Not hard.
>>
>> —
>> HLS
>>
>>
>> ___
> 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] AOL-compatible mailing lists

[Emanuel Schorsch]

+1 to Doug's comments. I think an expected and desired state achievable in
the foreseeable future (based on the flows I see) is to require at least
some form of authentication (whether it's SPF, DKIM or ARC).

On Mon, Apr 10, 2023, 8:18 AM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:

> The AOL breach obviously just magnified a problem that was already in
> place - impersonation is a useful attack vector.   Email addresses do not
> have restricted distribution, and they fall into the hands of unwanted
> senders all the time.
>
> We currently have a regime of semi-mandatory sender authentication.   Some
> domain owners request it and some do not, some evaluators enforce it and
> some do not.  Recipients assume that apparent identities can be trusted,
> generally without understanding the nuances between Friendly Name, From
> Address, and MailFrom address.   At the same time, some participants
> (including but not limited to mailing lists) depend on absence of sender
> authentication, at least on their unauthenticated traffic, a practice which
> works only as long as their traffic is not be impersonated.  The whole
> configuration is inherently unstable because domain owners and evaluators
> can change their policy at any time, and unauthenticated traffic can
> collect impersonators at any time.
>
> The stable designs involve no authentication and mutual distrust, or
> mandatory authentication.   Neither outcome is likely in the short term, so
> the instability will persist.   I don't know that our document can make
> much impact either way.I think language which most closely reflects
> reality is the tone that I have been pushing:   "Sender Authentication is
> too important to ignore, but too imperfect to trust unconditionally."
>
> Doug Foster
>
>
>
> On Mon, Apr 10, 2023 at 2:00 AM Wei Chuang  40google@dmarc.ietf.org> wrote:
>
>>
>>
>> On Sun, Apr 9, 2023 at 2:28 PM Murray S. Kucherawy 
>> wrote:
>>
>>> On Sun, Apr 9, 2023 at 2:07 PM Douglas Foster <
>>> dougfoster.emailstanda...@gmail.com> wrote:
>>>
 As an evaluator, what I can accept is that "Some intermediaries could
 be allowed to make some changes y do want unrestricto messages, if I have a
 list of intermediaries that should be allowed, sufficient reason to trust
 what they propose to do, and a reliable way to identify them."I do
 exceptions all the time.   But lists don't want to make special
 arrangements with evaluators, and don't want to make special arrangements
 with senders.  Apparently, lists don't even want to do rigorous
 verification to ensure that a post comes from the purported subscriber.
  But theted access to evaluators that filter based on simplistic triggers
 like "p=reject".

>>>
>>> I see two issues with this line of thinking:
>>>
>>> (1) "I do exceptions all the time" works when you are a relatively small
>>> operator with a relatively small user base for whom you need to configure
>>> exceptions.  You can get away with doing those manually.  What size staff
>>> do you imagine GMail would need to hire to investigate and configure manual
>>> exceptions on a timely basis for each time one of its billion-plus users
>>> wants to subscribe to a mailing list?  The notion screams for automation,
>>> and automation screams for something deterministic or at least close to it
>>> upon which to base automated decisions.  That last bit is what's missing
>>> here.
>>>
>>
>> +1
>>
>>
>>> (2) "But lists don't want to make special arrangements with evaluators,
>>> and don't want to make special arrangements with senders".  They might, if
>>> there existed a reliable way to do so.  How would you accomplish this in a
>>> way that prevents an attacker from making you think he's a list, and then
>>> sending whatever he wants from inside that trust boundary?
>>>
>>
>> +1
>>
>> FWIW I'm starting to think this problem has two parts:
>> 1) We know that a sender intends to send a message down some path that
>> may include a mailing list, that got to me safely.  This is to avoid DKIM
>> replay and FROM spoofing attacks.
>> 2) That we can identify the contributors to the content of the message in
>> that path to distinguish malicious vs benign contributors.  For certain
>> constrained but hopefully reasonable scenarios of mailing list
>> modifications, we might be able to distinguish the sources of content.  If
>> necessary, we can go back to first principles to determine which
>> modifications have to be supported.  For example I've seen Brandon mention
>> that mailing list appending disclosure footers are required for compliance
>> sometimes.  Others hopefully we would not have to support to reduce
>> implementation complexity.
>>
>>
>>>
>>> I think evaluators SHOULD NOT block on simplistic rules like p=reject,
 because a correct p=reject block requires follow-on work to block
 everything else from that malicious source, and should not be done
 incorrectly.   They