Okay everyone. We’ve veered way off the explicit consideration for this thread and are far past the deadline we’d communicated.
At this point, there seems to be good consensus on rechartering to consider Trent’s draft and discuss moving ARC to historic or obsolete now, vs later as part of a DKIM2 cluster. Seth, as Chair -mobile On Tue, Feb 24, 2026 at 07:19 Douglas Foster < [email protected]> wrote: > 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] >
_______________________________________________ dmarc mailing list -- [email protected] To unsubscribe send an email to [email protected]
