p=none is one solution, the other ( interoperable method) is to exempt the traffic from whatever process is breaking DKIM (i.e. external subject/body warning tags, URL rewriting, etc.). But that's a per-customer fix.
I've seen similar flows for forwarding of mail that customers send to email addresses that then send to ticketing systems which also check email authentication with Spamassassin. They were accommodated for by exempting said traffic from intrusive message modifications to preserve DKIM/SMIME/PGP, etc. To your point, until most corporate email security filters (and everyone else) seal ARC, workarounds like this are unfortunately necessary. - Mark Alley On Wed, May 8, 2024, 5:48 AM Laura Atkins <la...@wordtothewise.com> wrote: > > > On 8 May 2024, at 02:25, Scott Kitterman <skl...@kitterman.com> wrote: > > On Tuesday, May 7, 2024 9:09:02 PM EDT Mark Alley wrote: > > On 5/7/2024 7:00 PM, Dotzero wrote: > > https://www.ic3.gov/Media/News/2024/240502.pdf > > This was released this past week by the FBI. Although we are in last > call, I have to wonder if a) the attack itself, and/or b) the > government recommendations regarding policy might impact DMARCbis in > any manner. I've only just started thinking about the attack itself > and potential implications. > > Michael Hammer > > > While the subject is interesting, in my eyes, Business Email Compromise > (BEC), and a non-preferential DMARC policy disposition published by the > spoofed domain owner aren't an issue with the DMARC mechanism itself. > The receiving mail system did exactly what the domain owner requested > with p=none, no disposition was taken on email(s) failing DMARC. > > From an alternate point of view, one might consider how this policy > could be more broadly "exploitable" as a side effect now that the > internet email ecosystem is inundated with p=none DMARC records by > domain owners just doing the bare minimum to meet ESP sender > requirements, but that's still not a problem with DMARC itself. > > Addressing this issue - perusing Section 5.5.6, is there anything else > we could add that would be acceptable language in an Standards track > document to encourage urgency behind a transitory state of p=none use by > domain owners? Would that even make sense to do? (Legitimate question > for the WG) > > > I don't think the claim that p=none is "transitory" is at all generally > correct. It will be in some cases and not others. > > > I’m currently dealing with a client that sends notification emails to > their customer businesses. Those businesses forward the messages out to > their employees. DMARC breaks during the forwarding process - my guess is > that it’s due to the business filtering appliances modifying the body of > the message on inbound - adding “external” or modifying links. > > The mail is all isolated on a subdomain that’s only used for these > notifications. The domain had p=reject but a lot of the notifications were > being rejected due to that policy. > > I’m not sure what the actual solution is here, but for the short term I > told the client to move to p=none because they are being paid to send these > notifications and the notifications are failing. These kinds of indirect > corporate mail flows seem to be an increasing problem - I saw another > report of the same issue. I’m interested in hearing what the practical and > implementable solutions are here. I brought it up on one forum and the only > suggestion I got was to “add the forwarding systems to SPF.” I said no, > because that’s unworkable. > > It seems to me that until ARC is in widespread use, there will be mail > that is too important to use p=reject for. > > laura > > -- > The Delivery Expert > > Laura Atkins > Word to the Wise > la...@wordtothewise.com > > Delivery hints and commentary: http://wordtothewise.com/blog > > > > > > > _______________________________________________ > dmarc mailing list -- dmarc@ietf.org > To unsubscribe send an email to dmarc-le...@ietf.org >
_______________________________________________ dmarc mailing list -- dmarc@ietf.org To unsubscribe send an email to dmarc-le...@ietf.org
