Re: [dmarc-ietf] dmarc-dmarcbis: add "req=dkim"

2024-02-10 Thread Hector Santos
+1 With 5617 was the DKIM=ALL policy - anyone can sign. Offered no authorization protection. dkim=discardable offers 1st party signaing protection — just like DMARC offers. Both failed in validating the 3rd party signer. All the best, Hector Santos > On Feb 8, 2024, at 11:26 AM, Jim

Re: [dmarc-ietf] dmarc-dmarcbis: add "req=dkim"

2024-02-08 Thread Jim Fenton
On 6 Feb 2024, at 14:47, Murray S. Kucherawy wrote: > On Tue, Feb 6, 2024 at 2:33 AM Jeroen Massar 40massar...@dmarc.ietf.org> wrote: > >> `req=dkim`: requires DKIM, messages not properly signed are then to be >> rejected/quarantined based on 'p' policy. >> > > This sounds like what RFC 5617

Re: [dmarc-ietf] dmarc-dmarcbis: add "req=dkim"

2024-02-08 Thread John R. Levine
Together with DMARC p=none as DKIM signature-presence is ignored and thus any email can pass. I don't understand. Me neither. I still don't see any reason to revisit this issue. Nothing has changed since the last time we argued about it. R's, John PS: About RFC 5617 At that time,

Re: [dmarc-ietf] dmarc-dmarcbis: add "req=dkim"

2024-02-08 Thread Murray S. Kucherawy
On Thu, Feb 8, 2024 at 2:31 AM Jeroen Massar wrote: > > Uh, no. ~all is a soft fail. > > Together with DMARC p=none as DKIM signature-presence is ignored and thus > any email can pass. > I don't understand. > It is not about 'trusting SPF' it is about indicating that when a DKIM > Signature

Re: [dmarc-ietf] dmarc-dmarcbis: add "req=dkim"

2024-02-08 Thread Todd Herr
On Thu, Feb 8, 2024 at 5:32 AM Jeroen Massar wrote: > [multiple responses aggregated] > > > On 6 Feb 2024, at 22:22, John R. Levine wrote: > > > >>> Unless something important has changed since the last time we took up > >>> and rejected this idea, I don't think we need to discuss it further. >

Re: [dmarc-ietf] dmarc-dmarcbis: add "req=dkim"

2024-02-08 Thread Jeroen Massar
[multiple responses aggregated] > On 6 Feb 2024, at 22:22, John R. Levine wrote: > >>> Unless something important has changed since the last time we took up >>> and rejected this idea, I don't think we need to discuss it further. >> >> Is the reasoning documented? I have checked the list

Re: [dmarc-ietf] dmarc-dmarcbis: add "req=dkim"

2024-02-06 Thread Murray S. Kucherawy
On Tue, Feb 6, 2024 at 2:33 AM Jeroen Massar wrote: > `req=dkim`: requires DKIM, messages not properly signed are then to be > rejected/quarantined based on 'p' policy. > This sounds like what RFC 5617 tried to do, minus the constraint that the signing domain be equal to the author domain,

Re: [dmarc-ietf] dmarc-dmarcbis: add "req=dkim"

2024-02-06 Thread Todd Herr
On Tue, Feb 6, 2024 at 3:26 PM Jeroen Massar wrote: > > > > On 6 Feb 2024, at 20:52, John Levine wrote: > > > > It appears that Jeroen Massar said: > >> Hi Folks, > >> > >> As DMARCbis is being updated, I would like to suggest a new tag > `required` shorted to `req`. > >> > >> ``` > >>

Re: [dmarc-ietf] dmarc-dmarcbis: add "req=dkim"

2024-02-06 Thread Jeroen Massar
> On 6 Feb 2024, at 20:52, John Levine wrote: > > It appears that Jeroen Massar said: >> Hi Folks, >> >> As DMARCbis is being updated, I would like to suggest a new tag `required` >> shorted to `req`. >> >> ``` >> `req=dkim`: requires DKIM, messages not properly signed are then to be >>

Re: [dmarc-ietf] dmarc-dmarcbis: add "req=dkim"

2024-02-06 Thread John Levine
It appears that Jeroen Massar said: >Hi Folks, > >As DMARCbis is being updated, I would like to suggest a new tag `required` >shorted to `req`. > >``` >`req=dkim`: requires DKIM, messages not properly signed are then to be >rejected/quarantined based on 'p' policy. > >The tag should allow

[dmarc-ietf] dmarc-dmarcbis: add "req=dkim"

2024-02-06 Thread Jeroen Massar
Hi Folks, As DMARCbis is being updated, I would like to suggest a new tag `required` shorted to `req`. ``` `req=dkim`: requires DKIM, messages not properly signed are then to be rejected/quarantined based on 'p' policy. The tag should allow future expansion by requiring multiple mechanisms to