Moin, thanks for the input! Some replies in-line.
On Fri, 2024-08-02 at 12:30 -0500, Mark Alley via mailop wrote: > > Many of their customers use External Warning Tags, which inserts > external warning text into the message body, obviously breaking the > original DKIM body hash. (i.e. DKIM breaking is entirely dependent on > the customer configuration) Ah, no, judging from the NDR, in this case, it is the urldefense feature breaking DKIM. > > Is the mail following this flow? > > [...] Yep. > If so, the Proofpoint-protected Google Workspace tenant owner needs > to configure it (workspace) to not enforce email authentication > policy, as SPF/DKIM auth will almost certainly be broken by the > filter, and DMARC (where applicable) will fail for nearly all mail. I sadly fear that the tenant falls into the not so small category of "academic institution that clouded out all services and did not retain sufficient in-house knowledge to be able to even have an email-addr. to write to where such a request from an external party, i.e., me, would be understood"; As such, getting them to fix things, is not really an option. > Odds are they're probably not receiving a lot of mail if this is the > case. Another prime example of not following configuration > requirements. Based on my experience, though, I am rather sure that users in such institutions are frequently wondering why so little mail actually makes it through. Tbh, when offering a service meddling with DKIM and SPF, I would expect proofpoint to have some end-to-end monitoring in place to catch these cases and notify corresponding customers. Setting something like that up should not be the largest user story ever. > SPF ~all would be the best case for maximum delivery with a strict > DMARC policy. DMARC p=none would technically fix the problem, but > obviously introduces more security concerns. Added ~all for now; Let's see if that helps. As written in my follow- up, though, it was already p=quarantine, so the message should not have bounced/p=none should not make a difference for bouncing. Anyway, let's see what ~all does to this issue. > I'm sure you know this - but... pls no. I do; And I am not really serious... Then again, I need to get a (somewhat-ish) important email delivered, and the sensible option you outlined (make the tenant fix their settings) is not really feasible; > Proofpoint doesn't seal ARC yet, unfortunately. Believe me, I've > vehemently begged for it from their Product teams, as have many > others. Great, where do I get in line to join in on the begging... ? ;-) With best regards, Tobias _______________________________________________ mailop mailing list [email protected] https://list.mailop.org/listinfo/mailop
