It would be silly to deny that ARC is about indirect mail flows. The reason it is perceived to be in the wrong camp is that DMARC focuses on originators of email, while ARC requires no changes for them. A possible tweak is to introduce an ARC-0, zero for originator, an optional ARC set with i=0:
ARC-0 is substantially equivalent to a weak signature. The ARC-Seal field proves that the originator was involved. ARC-Message-Signature is expected to be broken by forwarders. ARC-Authentication-Results may contain just an auth stanza, with a possibly redacted authenticated identity. Malicious self-styled forwarders can abuse ARC-0 in the same manner that they can abuse weak signatures. The functional difference w.r.t. conditional signatures is that the latter require the forwarding "trusted" domain to be explicitly mentioned by the first signer. That would increase security if we could devise methods to avoid being fooled by wannabe phishers who pretend to be MLMs in order to swindle a conditionally signed message out of our servers. Formal differences include not requiring a new DKIM version, but requiring a DMARC authorization for (some forms of) ARC. ARC-0 is to be added to every submitted message, or limited to addresses suspected to result in indirect mail flows. A message signed that way can be (ab)used to illicitly impersonate an authenticated user of the signing domain. Therefore, ARC-0 should only be added by low risk targets. When such a domain sees good feedback, it can publish a strict DMARC policy even though its mail is not purely transactional. jm2c Ale On Wed 11/May/2016 05:15:35 +0200 Brandon Long wrote: > My worry is that if DMARC started as a private mechanism for high value > targets and large msps to collaborate to lower the risk of phishing for > their shared users, and I don't want ARC to be perceived as breaking that. > > I don't want MSPs to have to come up with private lists of high value > targets again, or there being yet another policy enforcement standard for > "no, I really mean it this time". > > And yes, you're absolutely correct that there is an installed base of poor > forwarders, though I'm not clear if those can be fixed with ARC but not by > actually making forwarding work correctly in the first place. > Theoretically, some appliance or outbound gateway could blindly add an ARC > header to resolve it, I guess, or a pair of inbound/outbound gateways, to > work around the broken internal server. > > Anyways, it's food for thought, especially in regards to how arc and dmarc > intersect. > > Brandon > > On Tue, May 10, 2016 at 5:45 PM, John R Levine <[email protected]> wrote: > >> On the other hand, for purely transactional domains, it could be simpler >>> for the recipient to be able to easily find that ARC-ish mechanisms are not >>> authorized. >>> >> >> As is invariably the case here, except sometimes. It is my impression >> that there are forwarders that break DMARC signatures (MS Exchange is often >> cited) even for a message resent to a single address. >> >> Regards, >> John Levine, [email protected], Taughannock Networks, Trumansburg NY >> Please consider the environment before reading this e-mail. >> >> >> _______________________________________________ >> dmarc mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/dmarc >> > > > > _______________________________________________ > dmarc mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dmarc > _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
