Re: [mailop] Doesn't ARC substitute DKIM at Gmail inbound?
On Sat, 4 May 2024, Alessandro Vesely via mailop wrote: The last URL in the response says something about ARC: ARC checks the previous authentication status of forwarded messages. If a forwarded message passes SPF or DKIM authentication, but ARC shows it previously failed authentication, Gmail treats the message as unauthenticated. Isn't it overkill to put both DKIM /and/ ARC if you know the receiver implements both? I don't think so. DKIM proves that you did send it. ARC proves that you forwarded what you received ? In this case GMail can see that you forwarded the mail, but cannot prove that it really came from the original sender. I think that this way GMail can reject the email, or put it in the spam folder, but without blaming you. I am not sure that ARC is supposed to do what we think it is. -- Andrew C. Aitchison Kendal, UK and...@aitchison.me.uk ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Doesn't ARC substitute DKIM at Gmail inbound?
Andrew C Aitchison via mailop skrev den 2024-05-05 18:49: On Sat, 4 May 2024, Alessandro Vesely via mailop wrote: The last URL in the response says something about ARC: ARC checks the previous authentication status of forwarded messages. If a forwarded message passes SPF or DKIM authentication, but ARC shows it previously failed authentication, Gmail treats the message as unauthenticated. Isn't it overkill to put both DKIM /and/ ARC if you know the receiver implements both? I don't think so. DKIM proves that you did send it. ARC proves that you forwarded what you received ? without trustness ? ARC-signer/ARC-Sealers have to be trusted, to make any different is arc btw ensure tested in dmarc ?, trustness or ? In this case GMail can see that you forwarded the mail, but cannot prove that it really came from the original sender. I think that this way GMail can reject the email, or put it in the spam folder, but without blaming you. gmail users should stop using gmail, problem solved I am not sure that ARC is supposed to do what we think it is. if you run all without trustness nothing works ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Doesn't ARC substitute DKIM at Gmail inbound?
On 5/5/2024 9:49 AM, Andrew C Aitchison via mailop wrote: DKIM proves that you did send it. No it doesn't. But that certainly is a common misconception about DKIM. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net mast:@dcrocker@mastodon.social ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Doesn't ARC substitute DKIM at Gmail inbound?
Dave Crocker via mailop skrev den 2024-05-05 19:21: But that certainly is a common misconception about DKIM. not even if users have there own dkim selector ? ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Doesn't ARC substitute DKIM at Gmail inbound?
On Sun 05/May/2024 19:44:57 +0200 Benny Pedersen via mailop wrote: Andrew C Aitchison via mailop skrev den 2024-05-05 18:49: On Sat, 4 May 2024, Alessandro Vesely via mailop wrote: The last URL in the response says something about ARC: ARC checks the previous authentication status of forwarded messages. If a forwarded message passes SPF or DKIM authentication, but ARC shows it previously failed authentication, Gmail treats the message as unauthenticated. Isn't it overkill to put both DKIM /and/ ARC if you know the receiver implements both? I don't think so. DKIM proves that you did send it. ARC proves that you forwarded what you received ? without trustness ? An ARC-Signature is very much the same thing as a DKIM signature. They both prove that a message went through the signing server. Then, ARC additionally conveys authentication results, which is what makes it suited to forwarding. ARC-signer/ARC-Sealers have to be trusted, to make any different Trust is required if you're going to make decisions based on that seal, such as overriding DMARC policy. In the case at hand, the author domain DKIM signature was not valid and the DMARC record said p=none, so trust was not needed. is arc btw ensure tested in dmarc ?, trustness or ? DMARC adds policy. It requires the From: domain to be aligned with DKIM or SPF. When you forward you don't rewrite From:, so it's not aligned, and a DKIM signature wouldn't help getting a dmarc=pass. There's no requirement that ARC's d= be aligned with anything. (Should forwarders rewrite the bounce address?) The question is, since Gmail seems to require a DKIM signature just to make sure some domain is responsible for the message, doesn't an ARC seal cover the same requirement? Best Ale -- ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Doesn't ARC substitute DKIM at Gmail inbound?
On Mon, May 6, 2024 at 12:41 AM Alessandro Vesely via mailop < mailop@mailop.org> wrote: > > The question is, since Gmail seems to require a DKIM signature just to > make > sure some domain is responsible for the message, doesn't an ARC seal cover > the > same requirement? > The most that ARC can provide in the case where DKIM is required is to say that DKIM verified for hop N if it no longer does. In the more general sense, ARC can also prove that a message transited a certain ADMD. That said, one of the reasons ARC is not DKIM is because the implication of DKIM is that the signer is vouching for the ADMD authorization for the message, but we didn't want ARC to do the same. The challenge with Gmail's new rules and forwarding is that they want you to provide an authentication signal (spf or dkim), but you also don't really know what you're sending, so doing so can result in a negative effect on your reputation. How to square that circle is left as an exercise to the reader. DKIM signing or using SPF would potentially solve that. The flip-side is if the Gmail "dkim required for major senders" message could be talking about the actual source before forwarding, in which case adding dkim or spf at the forwarder won't help. The request then is more like DMARC, looking for some level of alignment between the source and authentication. ARC was designed to help for that case, assuming the message was DKIM signed in by the sender in the first place. Unfortunately, one of the reasons that ARC is experimental is that solving the "trust" part on forwarding is non-trivial well, sorta, explicit opt-in of forwarders would work fine. In the case of someone forwarding their mailbox from a to b, having that specific account say "I'm forwarding from A, accept forwarded mail from them" would solve the issue,at the challenge of requiring user opt-in. Even then, at the spam rule level you need to decide on a rule by rule basis whether to accept ARC override or not... you can probably get away with having a general authentication signal that does, and more specific signals that don't, and using the right ones where you need to. Brandon ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Doesn't ARC substitute DKIM at Gmail inbound?
On Mon 06/May/2024 19:00:24 +0200 Brandon Long wrote: On Mon, May 6, 2024 at 12:41 AM Alessandro Vesely via mailop wrote: The question is, since Gmail seems to require a DKIM signature just to make sure some domain is responsible for the message, doesn't an ARC seal cover the same requirement? > [...] The challenge with Gmail's new rules and forwarding is that they want you to provide an authentication signal (spf or dkim), but you also don't really know what you're sending, so doing so can result in a negative effect on your reputation. How to square that circle is left as an exercise to the reader. DKIM signing or using SPF would potentially solve that. Fair enough, thank you. I replace the bounce address (because in case of problems I need to inform the recipient rather than the author) so they're authenticated, albeit unwillingly and unaligned. For reputation, I skip forwarding messages with SA score >= 9. ARC seems to be a useless exercise, for the time being. The flip-side is if the Gmail "dkim required for major senders" message could be talking about the actual source before forwarding, in which case adding dkim or spf at the forwarder won't help. The request then is more like DMARC, looking for some level of alignment between the source and authentication. ARC was designed to help for that case, assuming the message was DKIM signed in by the sender in the first place. Unfortunately, one of the reasons that ARC is experimental is that solving the "trust" part on forwarding is non-trivial well, sorta, explicit opt-in of forwarders would work fine. In the case of someone forwarding their mailbox from a to b, having that specific account say "I'm forwarding from A, accept forwarded mail from them" would solve the issue,at the challenge of requiring user opt-in. Yeah, I briefly discussed with your colleague Wei Chuang about experimenting that way to fix forwarding... But that's another topic. Best Ale -- ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop