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]
