It seems that in this case, Outlook has exposed a problem that will be latent in other environments. Elsewhere, it would not occur until a forward actually occurs. And even then, the root cause will not be detected or fixed unless we make it visible
As for making Microsoft behave, why cant we find someone who can convince them to publish their private registry domains in the PSL? They seem impermeable. Or perhaps they intend to expose the limitations of all of our email authentication techniques. If so, point taken. DF On Fri, Sep 13, 2024, 7:44 PM Mark Alley <mark.alley= [email protected]> wrote: > On 9/13/2024 5:59 PM, Douglas Foster wrote: > > We have a significant problem with broken ARC chains, and it is caused by > email security providers. I think the only way to get the issue > addressed is to give it visibility, by including an ARC chain verification > option in the DMARC aggregate reports. > > Here is the triggering scenario: > > Outlook.com client is configured to use a commercial email filter on > outbound messages. > > - Client user sends a message to me, via the Outlook.com mail store > server. > - Outlook.com creates an ARC Set before sending the message out of > their environment. > - Outlook.com delivers the message to the email filtering vendor, > which adds a client signature to the message but also breaks prior > signatures. (The nature of the alteration is not perceptible.) > - My inbound gateway checks ARC on every incoming message, amd logs > pass, fail, or none. Because of the client signature, the message passes > DMARC, but because of the changes made at the same time, the final > ARC-Message-Signature fails, and the chain status is Fail. > > It appears that the affected vendors include IronPort, ProofPoint, > ForcePoint, and Sophos, among others. > > Obviously, the solution is for those email filtering vendors to fix their > chain-breaking code, but before that can happen, they need to get some > complaints. To get some complaints, the problem needs visibility. I > don't know how to change the status quo unless DMARC reports carry the > problem back to the clients of those vendors. > > Doug Foster > > > IMO, this is a self-perpetuated problem with the logic in which said mail > store handles ARC sealing indiscriminately, and (anecdotally) they are the > only ones I've personally seen with the problem you speak of. > > With mail filters, it is not uncommon to see their customers remove > Exchange Online infrastructure from their SPF records, and move DKIM > signing to the perimeter mail filter. > > When ARC is sealed in this scenario with a message submitted via Outlook, > the message's ARC-Authentication-Results from the mail store will contain > inaccurate authentication results, since the message was never > authenticated to begin with, as the authentication happens after it leaves > the mail store and is emitted and signed via the mail filter. > > In both scenarios, ARC is sealed at the initial submission of an egress > email through their infrastructure, even if it wasn't actually a > forwarded/relayed email. And In some cases, I've seen some admins opt to > strip the outbound ARC set due to it failing authentication before it was > ever even actually authenticated in the first place. > > I would think this problem would be more easily fixed by correcting the > sealing logic. > > - Mark Alley > > > _______________________________________________ > 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]
