IMO, Trent’s proposed charter is acceptable as written. -- Alex Brotman Sr. Engineer, Anti-Abuse & Messaging Policy Comcast
From: Trent Adams <[email protected]> Sent: Tuesday, March 3, 2026 2:43 PM To: Seth Blank <[email protected]> Cc: IETF DMARC WG <[email protected]> Subject: [dmarc-ietf] Re: Proposed Recharter to Conclude the ARC Experiment Seth - Thanks for keeping us on track. In my initial proposal I’d offered up a rough draft charter that might work: https://github.com/ietf-artarea/charters/blob/main/dmarc/charter.md<https://urldefense.com/v3/__https:/github.com/ietf-artarea/charters/blob/main/dmarc/charter.md__;!!CQl3mcHX2A!C7acCrGGKevGgw-U6IJ3LhVJRsPzpsxOrBGV1jAalHEcmnifsnfYCCWrQNSm7DjSYKLj7LBJxPvkT3kjpUyn-0IvYgWQNHEW7bk$> Do you (or anyone else) think this is a reasonable start and/or need any tweaking to keep the ball rolling? Thanks again, Trent From: Seth Blank <[email protected]<mailto:[email protected]>> Date: Tuesday, February 24, 2026 at 7:28 AM To: Douglas Foster <[email protected]<mailto:[email protected]>> Cc: IETF DMARC WG <[email protected]<mailto:[email protected]>> Subject: [dmarc-ietf] Re: Proposed Recharter to Conclude the ARC Experiment This Message Is From an External Sender This message came from outside your organization. Report Suspicious<https://us-phishalarm-ewt.proofpoint.com/EWT/v1/ORgEfCBsr282Fw!YLP3Cs_b1lDt1nhc9fr-2w9M_Rx3ZWKmlGkDo9B5M6WfToO8zidfJ3wy0aCZXLMLASH79vzOCZpffEFpBQHiEL_nQ4eJygF6jrpv1ywlsT2GWzg1gzGMPqed4yK0$> 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]<mailto:[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]<mailto:[email protected]>> wrote: On Sun 22/Feb/2026 02:27:06 +0100 Richard Clayton wrote: > In message > <CAH48Zfwx0eSOEof9V73j+omeyph2=pcv0wrb3fhvnoaajnc...@mail.gmail.com<mailto:[email protected]>>, > Douglas Foster > <[email protected]<mailto:[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]<mailto:[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]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]> _______________________________________________ dmarc mailing list -- [email protected]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]>
_______________________________________________ dmarc mailing list -- [email protected] To unsubscribe send an email to [email protected]
