Re: [mailop] Doesn't ARC substitute DKIM at Gmail inbound?

2024-05-07 Thread Alessandro Vesely via mailop

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


Re: [mailop] Doesn't ARC substitute DKIM at Gmail inbound?

2024-05-06 Thread Brandon Long via mailop
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?

2024-05-06 Thread Alessandro Vesely via mailop

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?

2024-05-05 Thread Benny Pedersen via mailop

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?

2024-05-05 Thread Dave Crocker via mailop


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?

2024-05-05 Thread Benny Pedersen via mailop

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?

2024-05-05 Thread Andrew C Aitchison via mailop


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


[mailop] Doesn't ARC substitute DKIM at Gmail inbound?

2024-05-04 Thread Alessandro Vesely via mailop

Hi,

I sometimes get this response:

   421-4.7.30 This mail has been rate limited because DKIM does not pass. Gmail
   421-4.7.30 requires all large senders to authenticate with DKIM.
   421-4.7.30
   421-4.7.30 Authentication results:
   421-4.7.30 DKIM = did not pass
   421-4.7.30 For instructions on setting up DKIM authentication, go to
   421-4.7.30 https://support.google.com/a/answer/180504
   421-4.7.30 To learn more about Gmail's sender policy, go to
   421 4.7.30 https://support.google.com/mail/answer/81126. (token) - gsmtp

It was a forwarded message, so it might happen something went wrong, albeit I 
try and avoid applying changes on forwarded messages.  (Besides, I'm no large 
sender.)


Since I implemented ARC, I don't add a DKIM signature to forwarded messages any 
more, and apply an ARC set instead.  Unfortunately, I get no feedback about 
that, as ARC is missing a reporting part.  I guess Google does verify ARC.


I know that any DKIM or ARC signature has no DMARC relevance on forwarded 
messages, where d= doesn't match the From: domain.  However, the above response 
doesn't mention DMARC, so I wonder whether that message would have passed if I 
had put DKIM instead or ARC.


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?



Best
Ale
--




___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop