[Ietf-dkim] Re: DKIM with body length

> On 19 May 2024, at 17:32, Jim Fenton wrote: > > [adding the mailmaint mailing list] > > > On 19 May 2024, at 9:26, Wei Chuang wrote: > >> Hi DKIM folks, >> As many of you know there was a DKIM security vulnerability disclosure >> Friday around the signature header body length tag "l=". >

Re: [Ietf-dkim] What makes this posting different from the original posting?

> On 30 Aug 2023, at 09:21, Alessandro Vesely wrote: > > On Wed 30/Aug/2023 06:20:47 +0200 Steve Atkins wrote: >>> On 30 Aug 2023, at 03:38, Grant Taylor >>> wrote: >>> On 8/29/23 3:15 PM, Steve Atkins wrote: >>>> Any attempt by senders t

Re: [Ietf-dkim] What makes this posting different from the original posting?

> On 30 Aug 2023, at 06:35, Murray S. Kucherawy wrote: >> > > This also presumes that operators currently develop reputation based on (d=, > s=) pairs. Is that so? I thought it was mostly just the d= that matters. That some major consumer mailbox providers use s= to track reputation is one

Re: [Ietf-dkim] What makes this posting different from the original posting?

Sent from my iPhone > On 30 Aug 2023, at 03:38, Grant Taylor > wrote: > > On 8/29/23 3:15 PM, Steve Atkins wrote: >> Any attempt by senders to filter outbound emails based solely on content is >> going to have a lot of false negatives and positives, wherever you dec

Re: [Ietf-dkim] What makes this posting different from the original posting?

Sent from my iPhone > On 29 Aug 2023, at 20:54, Dave Crocker wrote: > > On 8/29/2023 12:30 PM, Murray S. Kucherawy wrote: >> For (1), I presume the outbound site did not make a quality assessment that >> identified the message as "likely to be replayed". Does this reduce to the >> "don't s

Re: [Ietf-dkim] DKIM issues (tag "v=DKIM1", tag "p=")

> On 16 May 2023, at 15:16, Steve Atkins wrote: > > > >> On 16 May 2023, at 15:00, Jan Dušátko >> wrote: >> >> Hi, >> I would like to ask how you feel about the possibility of changing the >> conditions for DKIM keys stored in DNS. Best in

Re: [Ietf-dkim] DKIM issues (tag "v=DKIM1", tag "p=")

> On 16 May 2023, at 15:00, Jan Dušátko > wrote: > > Hi, > I would like to ask how you feel about the possibility of changing the > conditions for DKIM keys stored in DNS. Best in some future RFC release about > DKIM itself. I have a practical experience during review and cleaning of > thou

Re: [Ietf-dkim] Taking Responsibility

> On 13 Dec 2022, at 06:02, Evan Burke wrote: > > > On Mon, Dec 12, 2022 at 8:49 PM Murray S. Kucherawy > wrote: > At a recent meeting where I heard some mass senders talk about this problem, > the use of "x=" as a mitigation technique was raised. I was curious t

Re: [Ietf-dkim] DKIM reply mitigations: re-opening the DKIM working group

> On 20 Nov 2022, at 21:42, Dave Crocker wrote: > > On 11/20/2022 1:12 PM, Steve Atkins wrote: >>> On 20 Nov 2022, at 20:48, Dave Crocker wrote: >>> >>> Remembering that you kicked this off with a heuristic approach, I'm merely >>> noting t

Re: [Ietf-dkim] DKIM reply mitigations: re-opening the DKIM working group

> On 20 Nov 2022, at 20:48, Dave Crocker wrote: > > On 11/20/2022 12:31 PM, Steve Atkins wrote: >>> On 20 Nov 2022, at 16:30, Dave Crocker wrote: >>> >>> On 11/10/2022 5:32 AM, Steve Atkins wrote: >>>> A heuristic I’ve suggested previously is “

Re: [Ietf-dkim] DKIM reply mitigations: re-opening the DKIM working group

> On 20 Nov 2022, at 16:30, Dave Crocker wrote: > > On 11/10/2022 5:32 AM, Steve Atkins wrote: >> A heuristic I’ve suggested previously is “If the recipient’s email address >> is not in the To: or Cc: header then treat the mail as unsigned”. > > Even if it is show

Re: [Ietf-dkim] DKIM reply mitigations: re-opening the DKIM working group

> On 11 Nov 2022, at 15:19, Murray S. Kucherawy wrote: > > On Fri, Nov 11, 2022 at 11:42 AM Laura Atkins > wrote: > >> The MP limits the volume of messages that a user can send out. However, by >> signing even one message, it takes the responsibility for its

Re: [Ietf-dkim] DKIM reply mitigations: re-opening the DKIM working group

> On 11 Nov 2022, at 09:23, Laura Atkins wrote: > >> Ultimately, I don't think senders should DKIM sign mail they aren't willing >> to >> take responsibility for, since that's exactly what a DKIM signature is >> supposed to signify. > > They took responsibility for the single opt-in message

Re: [Ietf-dkim] DKIM reply mitigations: re-opening the DKIM working group

> On 10 Nov 2022, at 13:17, Murray S. Kucherawy wrote: > > On Thu, Nov 10, 2022 at 12:54 PM Laura Atkins > wrote: > In many cases, the reason the mail isn’t going out through the signing domain > is because the signing domain’s anti-spam heuristics are good eno

Re: [Ietf-dkim] x= and DKIM replay

> On 2 Mar 2022, at 19:42, Evan Burke wrote: > > > Hi, > > I'm reading the section in rfc6376 on the x= tag, specifically - > > INFORMATIVE NOTE: The "x=" tag is not intended as an anti-replay defense. > > Could anyone shed some light on the reasoning for this, by chance? I note > that th

Re: [Ietf-dkim] Adding an aim= tag to DKIM Signature Tag Specifications

On 12/05/2020 09:20, Alessandro Vesely wrote: On Tue 12/May/2020 00:08:15 +0200 Dave Crocker wrote: On 5/11/2020 1:33 PM, Jim Fenton wrote: There might also be the situation where a domain wants to delegate a key Hence my suggestion that figuring out such details is where discussion could ge

Re: [Ietf-dkim] Looking for a little help testing DKIM failure reports, thank you.

> On Dec 18, 2018, at 10:02 AM, Laura Atkins wrote: > > You never published your DKIM key in DNS. > > https://tools.wordtothewise.com/dkim/check/mta5.uits.uconn.edu;/dkim1 > > So the mail is being signed, but the signature is failing because there’s no > public key to use to verify. No, it