The Zoho situation is an interesting application of ARC. The forwarders are not altering the messages, so if the DMARC-enforcing domain was configured with signatures, their messages would have passed DMARC at the final destination. Without the signature, they should have been blocked already. Apparently Zoho had encountered a lot of domains which were DMARC-enforcing but not signing, so they were not enforcing DMARC at all. Then they implemented ARC, so that they could trust SPF alignment if the message was aligned before forwarding, and began enforcing DMARC at reception. But without ARC support at the forwarder, the sender configuration problem persists.
It also highlights the difficulty of being a forwarder. What to do if a message from a DMARC-enforcing domain sends you a message, does not sign it, and it needs to be forwarded? If you forward anyway, the final recipient may block the message, with or without notification, and blame you. You could apply the Zoho defense, and add your own ARC set, which may or may not be recognized and trusted. The forwarder is in a quandary, because the final recipient (a) may ignore DMARC and want the message even without DMARC PASS, (b) may enforce DMARC and ignore ARC, still blocking the message and blaming you, or (c) may enforce DMARC but honor your ARC set and allow the message because of ARC. Without knowledge of the final evaluator behavior, there is no correct answer. On Fri, Sep 24, 2021 at 6:56 AM Ken O'Driscoll <ken= [email protected]> wrote: > > > Well, I have had a deliverability related encounter with ARC in the wild, > and can report that ARC is actively being used by Zoho. > > > > A client was using Zoho for their service desk and messages started going > missing. The way these service desks work is that you forward say > [email protected] to a unique Zoho supplied email address which goes to > your service desk queue. > > > > On investigation, it was determined that the only messages going missing > were those originating from domains with an enforcing DMARC policy and > non-aligned/non-existent/broken DKIM. > > > > Correspondence with Zoho’s customer service revealed that they a) have > implemented ARC, b) expect every mailbox provider to also have implemented > ARC, and c) are making filtering decisions on that belief. They appear to > be maintaining their own internal trust db. And yes, I know that this is > ideally how we want ARC to work; Zoho are just eager and early to the > party. They were not receptive to my opinion on the flaw with their > strategy. > > > > In my client’s case, their ISP has no plans to implement ARC, so Zoho > grudgingly disabled the filtering for their account. > > > > This incident made me wonder how much stealth ARC is out there, i.e. it’s > not evident that it’s being used at all, or indeed for filtering decisions, > until you poke the organisation. > > > > Ken. > > > > *From:* dmarc <[email protected]> *On Behalf Of *Murray S. Kucherawy > *Sent:* Wednesday 22 September 2021 21:30 > *To:* IETF DMARC WG <[email protected]> > *Subject:* [dmarc-ietf] Experiments > > > > Is anyone in a position to comment on the ARC and PSD experiments and how > they're progressing? Deployment status? Data acquired thus far? > > > > -MSK > > > _______________________________________________ > dmarc mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dmarc >
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
