Yes, I know the vendors involved. Almost all of the broken are chains started by Outlook.com.
I have attempted to contact all of the vendors involved. Two are trying to find the bugs. One will deal with it over next 9 months as they implement full ARC support. Some are not interested because their clients are not complaining. Others are silent since I am not their customer. It speaks to how little importance that the big vendors place on authentication. If they cared about ARC, they would be noticing these problems on incoming messages and talking to their peers. But ARC is essential to detecting credential upgrade that occurs when Outlook.com accepts an impersonated message. That should not happen either, but it does. Conveniently, Microsoft creates an ARC set to tell us they have acted badly. My workaround will be to ignore ARC failures because spammers have little reason to think that ARC fraud will be useful -- at least for now DF On Wed, Jun 11, 2025, 7:49 AM Mark Alley <[email protected]> wrote: > Are said ARCs started by Microsoft? Is there any commonality in the i=1~2 > set sealers where the chain is broken? > > - Mark Alley > > On Wed, Jun 11, 2025, 6:02 AM Douglas Foster < > [email protected]> wrote: > >> I have recently noticed that 25% of all ARC chains arrive broken, because >> of outbound gateway services that make unintended changes. Messages still >> pass DMARC, because the vendors add a client signature after the cause the >> damage. Nonetheless, trust is broken and mailing list problems return. >> >> Is this event covered by either aggregate reporting or failure >> reporting? >> >> DF >> _______________________________________________ >> 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]
