Ale, I don't understand the "global trust" issue. Each evaluator decides
what to trust. A mailing list may want a way to ensure that every
recipient organization treats its messages equally and favorably, but this
is not going to happen and was not an asserted goal of ARC. Each
organization decides, independently, which ARC data it wants to accept.
Richard's complaint went much deeper, arguing that even data from a
trusted participant could not be trusted. I think his problem occurs when
the message passes more than one intermediary. With multiple
intermediaries, the recipient needs to be able to trust each one, whether
they add an ARC set or not, or the ARC set itself becomes untrustworthy.
It is necessary to trust somebody, or there would be no reason to accept
any incoming email. But it is also true that trust can be betrayed, and
betrayal by a trusted actor tends to be more damaging than malicious action
by an untrusted actor. Trust makes a person an insider, so betrayal of
that trust becomes an insider attack. I have found this to be a powerful
principle for email filtering. There are three types "insiders":
- Members of my organization who log into my email server.
- External senders whose identity is verified and who are explicitly
trusted as evidenced by some type of allow rule to prevent wanted messages
from being blocked.
- External senders whose identity is verified and who are implicitly
trusted because they have sent us previous messages which have not been
flagged by spam filtering, have not been flagged by user complaints, and
have not caused visible harm to our organization.
Attacks from these insiders are dangerous exactly because they are
trusted. Email filtering is based on three prongs: (1) Do I know who
you are? (2) Do I know your reputation, and (3) Is your message content
acceptable? For an insider, the first two answers are favorable, and the
third question is answered with a high degree of grace. We assume that
betrayal by a trusted actor will involve account compromise, and the nature
of messages sent from a compromised account is nearly impossible to
forecast, so filtering to detect a future compromise is very difficult.
This analysis has fundamental implications for my filtering strategy:
- Trusted senders are only trusted if they have been properly
identified, so all accepted messages must be verified using a mixture of
public data and private knowledge.
- Essentially all threats will come from new senders, so I need to
distinguish between known and unknown senders.
- Whitelisting a known sender is a relatively low-risk decision.
Whitelisting a known brand name can simplify detection of malicious brand
impersonation, buried in the message body, and received from an unknown
sender.
- Allowed messages from unknown senders must be given after-the-fact
review for risk assessment, which may include reversing the message out of
the user's inbox. The safer strategy would be to quarantine all messages
from unknown senders, but this does not yet seem feasible.
- The primary purpose of content filtering is to detect old attack
strategies sent from new domains. New attacks from new domains are nearly
impossible to intercept (but perhaps AI will help.)
To my mind, the typical email defense strategies fail because:
- allowed messages are not reliably identified and
- known senders are not reliably distinguished from unknown senders.
DF
On Mon, Feb 23, 2026 at 12:45 PM Alessandro Vesely <[email protected]> wrote:
> On Sun 22/Feb/2026 02:27:06 +0100 Richard Clayton wrote:
> > In message <CAH48Zfwx0eSOEof9V73j+omeyph2=
> [email protected]>, Douglas Foster <
> [email protected]> writes
> >
> >> Auto-forwarding creates reputation risk and information leakage risk to
> >>the forwarding organization, so it should be approved by sending domain
> >>administration.
> >
> > for large sending systems (and most smaller ones) that just isn't going
> > to happen... there is a proposal floating around (which may make it to
> > the IETF in due course) to authenticate sign-ups to newsletters &c which
> > will be valuable, but that is in a different space
>
>
> That's interesting. Any pointer?
>
>
> > [...]
> >
> >>On Sat, Feb 21, 2026 at 9:08 AM Tero Kivinen <[email protected]> wrote:
> >
> >>> Such trust does not exists.
> >
> > I am a great believer in NSA's definition of trust .. a trusted
> > component is one that will screw you over when it breaks.
>
>
> :-)
>
>
> > Hence trust is not something to aim for, but something to avoid whenever
> > that might be possible.
>
> Yet, global trust is what ARC specification aimed to since the beginning.
>
> In Aug 2020, Todd wrote to arc-discuss:
>
> As to why you would trust the mailing list server, in my opinion,
> that's
> one of the bigger challenges that the community is still wrestling
> with.
> ARC is an attempt to capture authentication check results observed in
> transit for a message, with the goal being to mitigate failures that
> might
> occur due to the message transiting multiple hops, and ensure that
> messages
> that pass through mailings list or other intermediaries can still be
> accepted. Whether to trust ARC header sets, however, is an individual
> decision for each domain to make, and there's no consensus white list
> at
> this time.
>
> And that's precisely why ARC failed. But it is not trust in general that
> should be avoided. There's no point in verifying a signature if it
> doesn't
> provide any trust signal. The type of trust Tero claims doesn't exist is
> the
> one tied to global reputation. Large providers handle different types of
> mailing; you cannot trust everyone or no one. There should be specific
> agreements that signatures reference.
>
>
> Best
> Ale
> --
>
>
>
>
>
> _______________________________________________
> dmarc mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
>
_______________________________________________
dmarc mailing list -- [email protected]
To unsubscribe send an email to [email protected]
