Re: [Ietf-dkim] Taking Responsibility

2022-12-09 Thread mikespecter
Regardless of who created the protocol, it’s important to acknowledge that it had an effect that is actively creating harm, to the point that it’s a geostrategic concern. There are reasonable solutions that do not harm its original goal of fighting spam and spearfishing and we should pursue

Re: [Ietf-dkim] Taking Responsibility

2022-12-09 Thread Michael Thomas
On 12/9/22 6:14 PM, Jim Fenton wrote: On 9 Dec 2022, at 17:00, Michael Thomas wrote: On 12/9/22 4:53 PM, Dave Crocker wrote: On 12/9/2022 4:41 PM, Michael Thomas wrote: Considering that I was one of three original designers You worked on Domainkeys? When Yahoo asked me to be one of their

Re: [Ietf-dkim] Taking Responsibility

2022-12-09 Thread Michael Thomas
Yeah, your own website. Sorry if I don't give this any credence. Mike On 12/9/22 7:10 PM, Dave Crocker wrote: On 12/9/2022 6:14 PM, Jim Fenton wrote: DomainKeys and IIM both preceded IETF’s DKIM effort and neither of them is DKIM. Just came across this.  I don't remember when the page was

Re: [Ietf-dkim] Taking Responsibility

2022-12-09 Thread Dave Crocker
On 12/9/2022 7:08 PM, Barry Leiba wrote: For what it's worth, I remember extensive discussions about having signatures remain verifiable after delivery, and I remember a significant, but not universal desire to do so. based on a quick search, the discussions don't seem to have occurred on

Re: [Ietf-dkim] Taking Responsibility

2022-12-09 Thread Dave Crocker
On 12/9/2022 6:14 PM, Jim Fenton wrote: DomainKeys and IIM both preceded IETF’s DKIM effort and neither of them is DKIM. Just came across this.  I don't remember when the page was first published, but the version date of what is there now says 2007: *What are the differences between

Re: [Ietf-dkim] Taking Responsibility

2022-12-09 Thread Barry Leiba
I have no formal role here, so please just take this as a plea from a participant: Let's please stop bickering: it's simply hindering a productive discussion of a charter, and it's clear that we can have endless back-and-forth messages in this vein for quite some time if we let ourselves. Please,

Re: [Ietf-dkim] Taking Responsibility

2022-12-09 Thread Dave Crocker
On 12/9/2022 4:13 PM, Dave Crocker wrote: DKIM's motivation was (and is) to create a noise-free channel, by reliably associating an accurate identifier to a message stream. This permits a receiver to evaluate the messages in that stream, without concern that it has been polluting by other

Re: [Ietf-dkim] Taking Responsibility

2022-12-09 Thread Michael Thomas
On 12/9/22 6:26 PM, Dave Crocker wrote: On 12/9/2022 6:14 PM, Jim Fenton wrote: The semantics and motivation behind a DKIM signature were determined by IETF consensus when it was standardized, and isn’t necessarily what the semantics and motivation behind a DomainKeys or IIM signature were.

Re: [Ietf-dkim] Taking Responsibility

2022-12-09 Thread Dave Crocker
On 12/9/2022 6:14 PM, Jim Fenton wrote: The semantics and motivation behind a DKIM signature were determined by IETF consensus when it was standardized, and isn’t necessarily what the semantics and motivation behind a DomainKeys or IIM signature were. So the fact that we use ._domainkeys.,

Re: [Ietf-dkim] Taking Responsibility

2022-12-09 Thread Michael Thomas
On 12/9/22 6:14 PM, Jim Fenton wrote: On 9 Dec 2022, at 17:00, Michael Thomas wrote: On 12/9/22 4:53 PM, Dave Crocker wrote: On 12/9/2022 4:41 PM, Michael Thomas wrote: Considering that I was one of three original designers You worked on Domainkeys? When Yahoo asked me to be one of their

Re: [Ietf-dkim] Taking Responsibility

2022-12-09 Thread Jim Fenton
On 9 Dec 2022, at 17:00, Michael Thomas wrote: > On 12/9/22 4:53 PM, Dave Crocker wrote: >> On 12/9/2022 4:41 PM, Michael Thomas wrote: >>> Considering that I was one of three original designers >> >> You worked on Domainkeys? >> >> When Yahoo asked me to be one of their outside reviewers, for

Re: [Ietf-dkim] Taking Responsibility

2022-12-09 Thread Dave Crocker
On 12/9/2022 5:15 PM, Michael Thomas wrote: And this is completely irrelevant, and a continued ad hominem. Stop it. Since this is the reference to a person, in the thread: On 12/9/2022 4:41 PM, Michael Thomas wrote: Considering that I was one of three original designers and wrote the first

Re: [Ietf-dkim] Taking Responsibility

2022-12-09 Thread Michael Thomas
On 12/9/22 5:06 PM, Dave Crocker wrote: On 12/9/2022 5:00 PM, Michael Thomas wrote: Domainkeys and IIM were convergent evolution. IIM was actually published first. I produced the first DKIM implementation followed by Murray a day or two later. Yahoo's Domainkeys was an operational system,

Re: [Ietf-dkim] Taking Responsibility

2022-12-09 Thread Dave Crocker
On 12/9/2022 5:00 PM, Michael Thomas wrote: Domainkeys and IIM were convergent evolution. IIM was actually published first. I produced the first DKIM implementation followed by Murray a day or two later. Yahoo's Domainkeys was an operational system, for at least two rounds of development and

Re: [Ietf-dkim] Taking Responsibility

2022-12-09 Thread Michael Thomas
On 12/9/22 4:53 PM, Dave Crocker wrote: On 12/9/2022 4:41 PM, Michael Thomas wrote: Considering that I was one of three original designers You worked on Domainkeys? When Yahoo asked me to be one of their outside reviewers, for their initial work, I don't recall your being involved. This

Re: [Ietf-dkim] Taking Responsibility

2022-12-09 Thread Dave Crocker
On 12/9/2022 4:41 PM, Michael Thomas wrote: Considering that I was one of three original designers You worked on Domainkeys? When Yahoo asked me to be one of their outside reviewers, for their initial work, I don't recall your being involved. This was considerably before there was the

Re: [Ietf-dkim] Taking Responsibility

2022-12-09 Thread Michael Thomas
On 12/9/22 4:13 PM, Dave Crocker wrote: The concern was and is generally about the broad messaging category called spam, and not specifically or solely the sub-category called phishing. The above reference to things happening in transit and some out of band mechanism sound interesting, but

Re: [Ietf-dkim] Taking Responsibility

2022-12-09 Thread Dave Crocker
On 12/9/2022 9:36 AM, Michael Thomas wrote: A lot of the early motivation for DKIM was that it might be helpful for combating phishing. At the time tons of email providers were open relay sewers. What DKIM allowed is that you could at least determine which domain was sending it if they

Re: [Ietf-dkim] Taking Responsibility

2022-12-09 Thread Michael Thomas
On 12/9/22 3:29 PM, Grant Taylor wrote: On 12/9/22 10:36 AM, Michael Thomas wrote: One of the original goals was that the sending domain could theoretically take responsibility for sending the mail. It was never defined what that might entail but since a protocol was never envisioned for

Re: [Ietf-dkim] Taking Responsibility

2022-12-09 Thread Grant Taylor
On 12/9/22 10:36 AM, Michael Thomas wrote: One of the original goals was that the sending domain could theoretically take responsibility for sending the mail. It was never defined what that might entail but since a protocol was never envisioned for this to happen in transit, it was tacitly

[Ietf-dkim] Taking Responsibility

2022-12-09 Thread Michael Thomas
A lot of the early motivation for DKIM was that it might be helpful for combating phishing. At the time tons of email providers were open relay sewers. What DKIM allowed is that you could at least determine which domain was sending it if they signed. Ideally you want to catch the phishing

Re: [Ietf-dkim] not removing signatures

2022-12-09 Thread Barry Leiba
> >> In some systems, sieve scripts and other filtering is done *after* the > >> MUA drops the message in the delivery mailbox. If that drop removes > >> the signature, that hampers the sieve/filtering process severely. A > >> sieve "redirect" becomes impossible, and the filtering would not be >

Re: [Ietf-dkim] Problem Statement

2022-12-09 Thread Grant Taylor
On 12/8/22 5:17 AM, Alessandro Vesely wrote: Those who do so are neatly classified as spammers. On one hand I agree. But on the other hand I disagree. One benign case is that webmas...@example.com is configured to forward to al...@example.com so that Alice A. can perform her function. Time

Re: [Ietf-dkim] not removing signatures

2022-12-09 Thread Alessandro Vesely
On Wed 07/Dec/2022 18:49:47 +0100 Laura Atkins wrote: On 7 Dec 2022, at 17:16, Barry Leiba wrote: The purpose of a DKIM signature is, as our original statement put it, to make sure that a message from your bank actually came from your bank, even if it passed through your alumni association.