Re: [Ietf-dkim] replay clues

2023-02-12 Thread Michael Thomas
On 2/12/23 1:47 PM, Murray S. Kucherawy wrote: On Sun, Feb 12, 2023 at 11:19 AM Michael Thomas wrote: It's certainly possible to collect data that might correlate something like "Subject signed vs. not signed" with a spam score, and that could feed in to a best practices document

Re: [Ietf-dkim] replay clues

2023-02-12 Thread Murray S. Kucherawy
On Sun, Feb 12, 2023 at 11:19 AM Michael Thomas wrote: > > It's certainly possible to collect data that might correlate something > like "Subject signed vs. not signed" with a spam score, and that could feed > in to a best practices document. I don't know who might be up for > investing the time

Re: [Ietf-dkim] replay clues

2023-02-12 Thread Michael Thomas
On 2/12/23 9:36 AM, Murray S. Kucherawy wrote: It's certainly possible to collect data that might correlate something like "Subject signed vs. not signed" with a spam score, and that could feed in to a best practices document.  I don't know who might be up for investing the time into such a s

Re: [Ietf-dkim] replay clues

2023-02-12 Thread Stephen Farrell
On 12/02/2023 17:28, Murray S. Kucherawy wrote: Have they not been getting consideration? I know I've been replying to many of his comments. I didn't mean to imply he was being ignored, sorry if it sounded that way. Cheers, S. OpenPGP_0xE4D8E9F997A833DD.asc Description: OpenPGP public key

Re: [Ietf-dkim] replay clues

2023-02-12 Thread Murray S. Kucherawy
On Sat, Feb 11, 2023 at 2:35 PM Michael Thomas wrote: > It's never been especially clear to me whether deployments do their > filtering up front, ie at the MX, or farther down the line. There are > certainly advantages to do it right at the MX with less burden on using AR > to signal all of what

Re: [Ietf-dkim] replay clues

2023-02-12 Thread Murray S. Kucherawy
On Sat, Feb 11, 2023 at 4:48 PM Stephen Farrell wrote: > FWIW, as this discussion has a bit of a flavour of one person > arguing with a bigger bunch of people, I'd like to say that > Mike is asking good questions that deserve consideration. > Have they not been getting consideration? I know I'v

Re: [Ietf-dkim] replay clues

2023-02-11 Thread Dave Crocker
On 2/11/2023 4:48 PM, Stephen Farrell wrote: asking good questions that deserve consideration. Steve, There is a draft problem statement that seeks to explore the problem space. Perhaps you can suggest specific additions to it that should be made and fleshed out? That is, after all, the usua

Re: [Ietf-dkim] replay clues

2023-02-11 Thread Stephen Farrell
Hiya, FWIW, as this discussion has a bit of a flavour of one person arguing with a bigger bunch of people, I'd like to say that Mike is asking good questions that deserve consideration. I don't have a position as to what may or may not be worth doing in this space, but I figure I'll find it eas

Re: [Ietf-dkim] replay clues

2023-02-11 Thread Michael Thomas
On 2/10/23 9:23 PM, Murray S. Kucherawy wrote: On Fri, Feb 10, 2023 at 8:09 PM Michael Thomas wrote: I've always thought that the likelihood of a protocol level solution for this issue is pretty close to zero if not zero. The various proposed solutions in the problem draft have

Re: [Ietf-dkim] replay clues

2023-02-10 Thread Scott Kitterman
On February 11, 2023 5:23:39 AM UTC, "Murray S. Kucherawy" wrote: >On Fri, Feb 10, 2023 at 8:09 PM Michael Thomas wrote: > >> I've always thought that the likelihood of a protocol level solution for >> this issue is pretty close to zero if not zero. The various proposed >> solutions in the pr

Re: [Ietf-dkim] replay clues

2023-02-10 Thread Murray S. Kucherawy
On Fri, Feb 10, 2023 at 8:09 PM Michael Thomas wrote: > I've always thought that the likelihood of a protocol level solution for > this issue is pretty close to zero if not zero. The various proposed > solutions in the problem draft haven't given me any reason to dissuade > me of that notion. > >