ARC trust is not just a binary. There are also ways that the ARC headers can be used even if the ARC sealer is not 100% trusted. In this case, adding ARC headers would help solve this particular issue (assuming the original message was authenticated with at least one of SPF or DKIM).
You can see Google's advice for forwarders here <https://support.google.com/a/answer/175365?hl=en> with the relevant section being "Add ARC headers to messages". On Wed, Sep 13, 2023 at 9:27 AM Jason R Cowart <jcow...@stanford.edu> wrote: > Hi Emanuel, > > > > Thanks very much for the suggestion. ARC would seem to offer exactly what > we need for this scenario, but I wasn’t sure of the level of trust the > major providers place in it at this point. Some Microsoft documentation ( > https://techcommunity.microsoft.com/t5/microsoft-defender-for-office/improving-defense-in-depth-with-trusted-arc-sealers-for/ba-p/3440707 > ) suggests their level of trust is limited, as tenant owners need to add > trust for specific ARC sealers. > > > > Are you saying that if our service that does this forwarding were to add > ARC headers then Gmail would authenticate the message based on the ARC > chain? Or is there an additional layer of trust you would need to extend > to us? > > > > Our current message routing and hygiene vendor doesn’t currently offer an > option to write ARC headers, although I did file an enhancement request > with them over a year ago on this and am prepared to push them on this if > it would solve this particular issue. > > > > Thanks, > > Jason > > > > *From: *Emanuel Schorsch <emschor...@google.com> > *Date: *Wednesday, September 13, 2023 at 12:24 AM > *To: *Jason R Cowart <jcow...@stanford.edu> > *Cc: *Brandon Long <bl...@google.com>, mailop@mailop.org < > mailop@mailop.org> > *Subject: *Re: [mailop] Authentication Bounces by Gmail > > Hi Jason, > > > > One additional thing worth investigating is adding ARC headers for the > forwarding cases. That has the potential to help with both downstream DMARC > evaluation as well as unauthenticated bounces. This is particularly > important if the DKIM signature is breaking or wasn't present in the first > place. > > > > Best, > > Emanuel > > > > On Tue, Sep 12, 2023, 11:48 PM Jason R Cowart via mailop < > mailop@mailop.org> wrote: > > Hi Brandon, > > > > Thank you for the responses. I’ll send you some examples off list of > successes and failures from the exact same sender and final recipient, both > Gmail users. I’d very much like to understand why we are seeing what > appears to be an increase in DKIM validation failures in order to determine > what can be done to improve the situation. We are aware of DKIM signatures > using the strict canonicalization option failing validation after > forwarding, but in these examples the relaxed canonicalization was used. > > > > We do not rewrite the envelope sender as we forward. I’m not convinced the > non-trivial effort needed to shift to rewriting the sender would yield a > durable solution to this problem, as it would not help with a DMARC check > since the resulting SPF pass will be out of alignment with the sender in > the From: header. It would seem we’re dependent on the initial DKIM > signature passing validation. I’d welcome any other perspectives on the > topic. > > > > Best, > > Jason > > > > > > *From: *Brandon Long <bl...@google.com> > *Date: *Tuesday, September 12, 2023 at 8:29 PM > *To: *Jason R Cowart <jcow...@stanford.edu> > *Cc: *mailop@mailop.org <mailop@mailop.org> > *Subject: *Re: [mailop] Authentication Bounces by Gmail > > Looking at the messages from that IP getting that rejection message, I'm > seeing a lot of DKIM body hash did not verify, I'd also verify that your > system isn't modifying the messages that it is forwarding. > > > > Brandon > > > > On Tue, Sep 12, 2023 at 8:20 PM Brandon Long <bl...@google.com> wrote: > > That message did not have a DKIM header ... or was so garbled that we > didn't extract it. > > > > Due to DKIM replay, we may spam reject forwarded messages that DKIM verify > but not SPF, but those would not have that rejection message. > > > > And yes, we are continuing to ramp no auth, no entry. > > > > I'm sure I've had a long explanation on here in the past year, but the > short answer is if the message is not DKIM valid and you're forwarding, you > should rewrite > > the MAIL FROM to a domain you own that will SPF authn the message... and > try not to forward spam. > > > > Brandon > > > > On Tue, Sep 12, 2023 at 6:00 PM Jason R Cowart via mailop < > mailop@mailop.org> wrote: > > We are seeing an increasing number of bounces by Gmail related to failed > authentication checks. The bounces include language like: > > <<< 550-5.7.26 This mail is unauthenticated, which poses a security risk > to > the > <<< 550-5.7.26 sender and Gmail users, and has been blocked. The sender > must > <<< 550-5.7.26 authenticate with at least one of SPF or DKIM. For this > message, > <<< 550-5.7.26 DKIM checks did not pass and SPF check for [mcn.org > <https://urldefense.com/v3/__http:/mcn.org__;!!G92We9drHetJ8EofZw!bcfdgTyulTUmQKo1vrF--AjiXti3tNVYB_Md2jNzKH5HdHgzwQrWe10SlqFuXZpImNccCVLZ-KAaRcSj$>] > did not > pass > <<< 550-5.7.26 with ip: [67.231.157.125]. The sender should visit > <<< 550-5.7.26 https://support.google.com/mail/answer/81126#authentication > <https://urldefense.com/v3/__https:/support.google.com/mail/answer/81126*authentication__;Iw!!G92We9drHetJ8EofZw!bcfdgTyulTUmQKo1vrF--AjiXti3tNVYB_Md2jNzKH5HdHgzwQrWe10SlqFuXZpImNccCVLZ-FftiJ0V$> > > for > <<< 550 5.7.26 instructions on setting up authentication. > z6-20020a05622a028600b00403a8e58423si1377805qtw.448 - gsmtp > 554 5.0.0 Service unavailable > > > > This is occurring in situations where our users forward their mail to a > personal Gmail account. SPF checks will of course fail in the scenario, > but DKIM checks should pass. In fact, they most often do pass—users > impacted by this are only seeing a small subset of their mail from a given > sender bounced (which often times will be a Gmail sender). In cases where > the user retains a copy locally we’ve been able to verify that the DKIM > signature was present and was successfully validated by our system. > > Is anyone else experiencing this? > > Is anyone from Google could reach out to me off-list to discuss that would > be much appreciated. > > > > Best, > > Jason Cowart > > Stanford University IT > > _______________________________________________ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop > <https://urldefense.com/v3/__https:/list.mailop.org/listinfo/mailop__;!!G92We9drHetJ8EofZw!bcfdgTyulTUmQKo1vrF--AjiXti3tNVYB_Md2jNzKH5HdHgzwQrWe10SlqFuXZpImNccCVLZ-DcfcSNP$> > > _______________________________________________ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop > <https://urldefense.com/v3/__https:/list.mailop.org/listinfo/mailop__;!!G92We9drHetJ8EofZw!afZGCYWAlrsX3TmWLonZ6bYZpmuPGx74bQvXOqCBhjYnJVfX-eay8wK94J30tr0qrccumt3o0927z3A9-3M4WLU$> > >
_______________________________________________ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
