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

On 11/20/2022 2:22 PM, Steve Atkins wrote: On 20 Nov 2022, at 21:42, Dave Crocker wrote: It’s a reasonable heuristic if Bcc is included in the DKIM signature, I just don’t think including Bcc in the DKIM signature is a good idea. Including Bcc: in the signature is a given, for this topic.

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 that a BCC with an addressee listed in it should be

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

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 that a BCC with an addressee listed in it should be just as valid (to the heuristic) as having it occur in To: or CC:.

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 “If the recipient’s email address is not in

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

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 “If the recipient’s email address is not in the To: or Cc: header then treat the mail as unsigned”. Even if it 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 showing in a (signed) BCC field?

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

On 11/10/2022 4:54 AM, Laura Atkins wrote: There are a couple of characteristics that stand out. A few of the posting here have provided substantive details about the nature of a replay attack.  Not just the overall concept but some detail about the means and methods. Whatever draft(s)

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

By way of explaining why I have offered an alternative draft charter... On 11/9/2022 4:08 AM, Barry Leiba wrote: DKIM Working Group Charter Domain Keys Identified Mail (DKIM, RFC 6376) defines a mechanism for using a digital signature to associate a domain identity with an email message in a

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

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 showing in a (signed) BCC field? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net

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

On Thu 17/Nov/2022 00:48:51 +0100 Roland Turner wrote: On 17/11/22 04:34, Alessandro Vesely wrote: On Wed 16/Nov/2022 05:35:52 +0100 Roland Turner wrote: [ARC seals are] Not quite [enough], because they're not usually applied when a message is forwarded intact. One outcome of the proposed WG

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

On 17/11/22 04:59, Alessandro Vesely wrote: > In the context of a replay attack, the important cases are: > > 1. the MLM does not break the original DKIM signature > 2. the MLM applies its own ARC/DKIM signature which is itself used in a reply > attack I fancied an experiment where a

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

On 17/11/22 04:34, Alessandro Vesely wrote: On Wed 16/Nov/2022 05:35:52 +0100 Roland Turner wrote: > Not quite, because they're not usually applied when a message is forwarded > intact. One outcome of the proposed WG might be to specifically encourage all > MLMs to ARC-sign, even if they

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

On 17/11/22 03:59, Hector Santos wrote: On Nov 11, 2022, at 11:46 AM, Barry Leiba wrote: Indeed... The issue here is this: 1. I get a (free) account on free-email.com . Ok 2. I send myself email from my account to my account.  Of course, free-email signs it,

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

On 16/11/22 19:20, Wei Chuang wrote: On Tue, Nov 15, 2022 at 4:10 AM Alessandro Vesely wrote: If you can filter basing on a reliable reputation system, current ARC seals are enough already, aren't they? There's the risk that ARC gets replayed like DKIM, so it too needs

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

On Wed 16/Nov/2022 05:32:24 +0100 Roland Turner wrote: On 15/11/22 03:01, Alessandro Vesely wrote: The exception is a standardised mechanism to allow a sender/signer to indicate the [approximate] number of intended recipients, with which receivers might make fact-based decisions about when to

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

On Wed 16/Nov/2022 05:35:52 +0100 Roland Turner wrote: On 15/11/22 23:10, Alessandro Vesely wrote: On Mon 14/Nov/2022 18:54:33 +0100 Wei Chuang wrote: > On Mon, Nov 14, 2022 at 8:03 AM Alessandro Vesely wrote: > >> BTW, we all know that mailing lists send one message at a time, doing >> VERP

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

> On Nov 11, 2022, at 11:46 AM, Barry Leiba wrote: > > Indeed... > The issue here is this: > > 1. I get a (free) account on free-email.com. Ok > 2. I send myself email from my account to my account. Of course, > free-email signs it, because it's sent from me to me: why would it > not?

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

> On 15 Nov 2022, at 12:29, Murray S. Kucherawy wrote: > > On Mon, Nov 14, 2022 at 11:04 AM Laura Atkins > wrote: > Does it make sense to add in a brief discussion of ‘responsibility for the > message'? As I see it, responsibility implies able to do something

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

On Tue, Nov 15, 2022 at 4:10 AM Alessandro Vesely wrote: > On Mon 14/Nov/2022 18:54:33 +0100 Wei Chuang wrote: > > On Mon, Nov 14, 2022 at 8:03 AM Alessandro Vesely > wrote: > > > >> BTW, we all know that mailing lists send one message at a time, doing > >> VERP for each subscriber. They can

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

On 15/11/22 23:30, Alessandro Vesely wrote: On Mon 14/Nov/2022 19:29:10 +0100 Evan Burke wrote: > On Mon, Nov 14, 2022 at 8:03 AM Alessandro Vesely wrote: > >>> The exception is a standardised mechanism to allow a sender/signer to >>> indicate the [approximate] number of intended recipients,

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

On 15/11/22 23:10, Alessandro Vesely wrote: On Mon 14/Nov/2022 18:54:33 +0100 Wei Chuang wrote: > On Mon, Nov 14, 2022 at 8:03 AM Alessandro Vesely wrote: > >> BTW, we all know that mailing lists send one message at a time, doing >> VERP for each subscriber. They can more easily include the

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

On 15/11/22 03:01, Alessandro Vesely wrote: > The exception is a standardised mechanism to allow a sender/signer to > indicate the [approximate] number of intended recipients, with which > receivers might make fact-based decisions about when to recognise an > instance of this particular attack

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

On November 16, 2022 4:11:27 AM UTC, Roland Turner wrote: >On 15/11/22 23:29, Murray S. Kucherawy wrote: > >> Wei might argue that their signature means "We attest that this passed >> through us, and we did our best to make sure it was legitimate before it >> went out", than the more

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

On 14/11/22 22:12, Alessandro Vesely wrote: On Mon 14/Nov/2022 01:26:29 +0100 Scott Kitterman wrote: > >> Because of DKIM’s broad deployment, compatibility with existing >> deployments will be a critical factor, and it is unlikely that proposals >> that lack compatibility will proceed to

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

On November 15, 2022 3:12:22 PM UTC, Barry Leiba wrote: >On Mon, Nov 14, 2022 at 11:03 AM Alessandro Vesely wrote: >> >> On Mon 14/Nov/2022 05:50:42 +0100 Roland Turner wrote: >> > I'd point out that all but one of those things is either redundant (vs. say >> > ARC), unacceptably harmful (we

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

On 15/11/22 23:29, Murray S. Kucherawy wrote: Wei might argue that their signature means "We attest that this passed through us, and we did our best to make sure it was legitimate before it went out", than the more absolute "We claim this is legitimate and we are willing to stake our

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

On 14/11/22 22:03, Laura Atkins wrote: Does it make sense to add in a brief discussion of ‘responsibility for the message'? As I see it, responsibility implies able to do something against the originator of the message or act to stop the message if it turns out to be a problem. If it’s your

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

On 14/11/22 20:38, Murray S. Kucherawy wrote: On Mon, Nov 14, 2022 at 12:26 AM Scott Kitterman wrote: Is compatibility with DKIM sufficient for  the charter or should there be broader language about compatibility with existing email architecture?  I'm inclined to say

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

On 14/11/22 20:34, Murray S. Kucherawy wrote: On Sat, Nov 12, 2022 at 7:32 AM Roland Turner wrote: On 11/11/22 23:09, Murray S. Kucherawy wrote: More concerning to me: The IETF has previously taken the position that the market will figure out spam and phishing, and therefore

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

On 14/11/22 20:07, Wei Chuang wrote: On Sun, Nov 13, 2022 at 8:50 PM Roland Turner wrote: On 13/11/22 03:05, Wei Chuang wrote: On Fri, Nov 11, 2022 at 11:17 PM Roland Turner wrote: 1. Unless one or more of the larger receivers (a) has a useful tool to

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

On Mon, Nov 14, 2022 at 11:03 AM Alessandro Vesely wrote: > > On Mon 14/Nov/2022 05:50:42 +0100 Roland Turner wrote: > > I'd point out that all but one of those things is either redundant (vs. say > > ARC), unacceptably harmful (we use DKIM *in the first place* to facilitate > > forwarding

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

On Mon, Nov 14, 2022 at 11:04 AM Laura Atkins wrote: > Does it make sense to add in a brief discussion of ‘responsibility for the > message'? As I see it, responsibility implies able to do something against > the originator of the message or act to stop the message if it turns out to > be a

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

On Mon 14/Nov/2022 18:54:33 +0100 Wei Chuang wrote: On Mon, Nov 14, 2022 at 8:03 AM Alessandro Vesely wrote: BTW, we all know that mailing lists send one message at a time, doing VERP for each subscriber. They can more easily include the recipient in the ARC signature. However, any spammer

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

On Mon, Nov 14, 2022 at 8:03 AM Alessandro Vesely wrote: > > > The exception is a standardised mechanism to allow a sender/signer to > > indicate the [approximate] number of intended recipients, with which > > receivers might make fact-based decisions about when to recognise an > > instance of

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

Just a comment on a narrow point below. On Mon, Nov 14, 2022 at 8:03 AM Alessandro Vesely wrote: > > > BTW, we all know that mailing lists send one message at a time, doing VERP > for > each subscriber. They can more easily include the recipient in the ARC > signature. However, any spammer

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

On Mon 14/Nov/2022 05:50:42 +0100 Roland Turner wrote: I'd point out that all but one of those things is either redundant (vs. say ARC), unacceptably harmful (we use DKIM *in the first place* to facilitate forwarding outside of the domain-registrant/sender's control), or both. +1, Scott is

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

On Mon 14/Nov/2022 01:26:29 +0100 Scott Kitterman wrote: Because of DKIM’s broad deployment, compatibility with existing deployments will be a critical factor, and it is unlikely that proposals that lack compatibility will proceed to publication. Is compatibility with DKIM sufficient for

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

> On 14 Nov 2022, at 09:41, Murray S. Kucherawy wrote: > > On Mon, Nov 14, 2022 at 12:42 AM Scott Kitterman > wrote: > > I don't think there's any point in pursuing solutions that require a human to > read/understand anything about header fields. > > Having

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

On Mon, Nov 14, 2022 at 12:42 AM Scott Kitterman wrote: > > I don't think there's any point in pursuing solutions that require a human > to read/understand anything about header fields. > > Having reviewed the proposals again, it seems like anything that actively > makes replays harder without

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

On Mon, Nov 14, 2022 at 12:26 AM Scott Kitterman wrote: > Is compatibility with DKIM sufficient for the charter or should there be > broader language about compatibility with existing email architecture? > I'm > inclined to say "Yes", but I'm unsure about wording. I also assume "Yes". I'm

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

On Sat, Nov 12, 2022 at 7:32 AM Roland Turner wrote: > On 11/11/22 23:09, Murray S. Kucherawy wrote: > > More concerning to me: The IETF has previously taken the position that the > market will figure out spam and phishing, and therefore consideration of > protocol solutions should be deflected.

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

On Sun, Nov 13, 2022 at 8:50 PM Roland Turner wrote: > On 13/11/22 03:05, Wei Chuang wrote: > > On Fri, Nov 11, 2022 at 11:17 PM Roland Turner 40rolandturner@dmarc.ietf.org> wrote: > >> >> >>1. Unless one or more of the larger receivers (a) has a useful tool >>to help with this

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

On 14/11/22 08:41, Scott Kitterman wrote: On November 12, 2022 6:46:13 PM UTC, Wei Chuang wrote: > >Received headers are generally not DKIM signed and spammers have >stripped/probably modified them. Another problem is that while a human can >interpret the domain names, IP and other

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

On 14/11/22 08:26, Scott Kitterman wrote: Is compatibility with DKIM sufficient for the charter or should there be broader language about compatibility with existing email architecture? I'm inclined to say "Yes", but I'm unsure about wording. +1 Similarly, at least one of them could lead

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

On 13/11/22 03:05, Wei Chuang wrote: On Fri, Nov 11, 2022 at 11:17 PM Roland Turner wrote: 1. Unless one or more of the larger receivers (a) has a useful tool to help with this problem, and (b) is willing to share operational experience, then we risk creating yet

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

On 13/11/22 21:06, Jim Fenton wrote: On Nov 12, 2022, at 8:32 AM, Roland Turner wrote:  On 11/11/22 23:09, Murray S. Kucherawy wrote: More concerning to me: The IETF has previously taken the position that the market will figure out spam and phishing, and therefore consideration of

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

On November 12, 2022 6:46:13 PM UTC, Wei Chuang wrote: >On Fri, Nov 11, 2022 at 9:31 PM Scott Kitterman >wrote: > >> On Friday, November 11, 2022 5:18:57 PM EST Wei Chuang wrote: >> > Sorry I'm late to this thread. >> > >> > On Thu, Nov 10, 2022 at 4:42 AM Scott Kitterman >> > >> > wrote:

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

On Friday, November 11, 2022 12:27:38 PM EST Scott Kitterman wrote: > On Friday, November 11, 2022 10:09:52 AM EST Murray S. Kucherawy wrote: > > On Fri, Nov 11, 2022 at 5:05 AM Scott Kitterman > > wrote: ... > > > I can imagine the market solving this. If there are two ESPs and one is > > >

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

On November 13, 2022 9:07:21 PM UTC, Jim Fenton wrote: >On 9 Nov 2022, at 13:08, Barry Leiba wrote: > >> Murray is looking at re-opening the DKIM working group, chartering it >> to work on replay mitigation. > >IIRC the result from Monday’s dispatch session was to go ahead and charter the

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

On 9 Nov 2022, at 13:08, Barry Leiba wrote: > Murray is looking at re-opening the DKIM working group, chartering it > to work on replay mitigation. IIRC the result from Monday’s dispatch session was to go ahead and charter the working group without a BOF. It seems to me that the discussion on

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

On Sat 12/Nov/2022 19:46:13 +0100 Wei Chuang wrote: On Fri, Nov 11, 2022 at 9:31 PM Scott Kitterman wrote: On Friday, November 11, 2022 5:18:57 PM EST Wei Chuang wrote: > On Thu, Nov 10, 2022 at 4:42 AM Scott Kitterman wrote: If a domain is signing spam and their reputation suffers as a

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

> On Nov 12, 2022, at 8:32 AM, Roland Turner > wrote: > >  >> >> On 11/11/22 23:09, Murray S. Kucherawy wrote: >> >> >> More concerning to me: The IETF has previously taken the position that the >> market will figure out spam and phishing, and therefore consideration of >> protocol

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 Fri, Nov 11, 2022 at 11:17 PM Roland Turner wrote: > On 12/11/22 00:46, Barry Leiba wrote: > > 2. I send myself email from my account to my account. Of course, > free-email signs it, because it's sent from me to me: why would it > not? > 3. I take that signed message and cart it over

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

On Fri, Nov 11, 2022 at 9:31 PM Scott Kitterman wrote: > On Friday, November 11, 2022 5:18:57 PM EST Wei Chuang wrote: > > Sorry I'm late to this thread. > > > > On Thu, Nov 10, 2022 at 4:42 AM Scott Kitterman > > > > wrote: > > > I agree that we don't want too much detail in the charter about

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

On 11/11/22 23:09, Murray S. Kucherawy wrote: More concerning to me: The IETF has previously taken the position that the market will figure out spam and phishing, and therefore consideration of protocol solutions should be deflected.  DMARC was the result.   I feel that we leave this to the

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

On 12/11/22 00:46, Barry Leiba wrote: 2. I send myself email from my account to my account. Of course, free-email signs it, because it's sent from me to me: why would it not? 3. I take that signed message and cart it over somewhere else, sending it out to 10,000,000 recipients through

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

On Friday, November 11, 2022 5:18:57 PM EST Wei Chuang wrote: > Sorry I'm late to this thread. > > On Thu, Nov 10, 2022 at 4:42 AM Scott Kitterman > > wrote: > > I agree that we don't want too much detail in the charter about the > > technical > > nature of the problem, but I would like to

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

On Fri, Nov 11, 2022 at 9:33 AM Scott Kitterman wrote: > OK. Let's alter your scenario slightly. > > In step 2, instead of sending to yourself, you send it to an email list > which > (as we have been begging them to do for 15 years) does not make any > changes in > the message to invalidate

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

Sorry I'm late to this thread. On Thu, Nov 10, 2022 at 4:42 AM Scott Kitterman wrote: > I agree that we don't want too much detail in the charter about the > technical > nature of the problem, but I would like to understand it in more detail in > order to better assess the appropriateness of

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

OK. Let's alter your scenario slightly. In step 2, instead of sending to yourself, you send it to an email list which (as we have been begging them to do for 15 years) does not make any changes in the message to invalidate that DKIM signature. So in step 3, the message goes to X thousands

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

On Friday, November 11, 2022 10:09:52 AM EST Murray S. Kucherawy wrote: > On Fri, Nov 11, 2022 at 5:05 AM Scott Kitterman > > 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

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

On Friday, November 11, 2022 4:23:44 AM EST Laura Atkins wrote: > Snipping a bunch. > > > On 11 Nov 2022, at 05:04, Scott Kitterman wrote: > >>> 2) The messages often have two different To: lines > >>> > >>> This violates RFC 5322, so it would be easy to filter these out, except > >>> that we

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

Indeed... The issue here is this: 1. I get a (free) account on free-email.com. 2. I send myself email from my account to my account. Of course, free-email signs it, because it's sent from me to me: why would it not? 3. I take that signed message and cart it over somewhere else, sending it out to

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

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 content. > > > This appears to be the disconnect. The MP takes responsibility for the > *MESSAGE* -

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

On Fri, Nov 11, 2022 at 5:05 AM Scott Kitterman 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”. > > Which is a fancy way of making DKIM only work for direct mail flows. > That's part of

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

> On 11 Nov 2022, at 13:06, Alessandro Vesely wrote: > >>> [*] Previous messages use ESP, which I tend to associate to operators like >>> Mailchimp, say, rather than Gmail. I had a hard time trying to understand >>> why ESPs would let folks send a single opt-in message... Is it me? >> Why

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

On Fri 11/Nov/2022 12:42:26 +0100 Laura Atkins wrote: On 11 Nov 2022, at 11:33, Alessandro Vesely wrote: On Fri 11/Nov/2022 10:23:44 +0100 Laura Atkins wrote: On 11 Nov 2022, at 05:04, Scott Kitterman wrote: [...] For those that have been around for awhile this reminds me of the now long

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

> On 11 Nov 2022, at 11:33, Alessandro Vesely wrote: > > On Fri 11/Nov/2022 10:23:44 +0100 Laura Atkins wrote: >>> On 11 Nov 2022, at 05:04, Scott Kitterman wrote: >>> [...] >>> >>> For those that have been around for awhile this reminds me of the now long >>> dead controversy about closing

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

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

Snipping a bunch. > On 11 Nov 2022, at 05:04, Scott Kitterman wrote: > >>> >>> >>> 2) The messages often have two different To: lines >>> >>> This violates RFC 5322, so it would be easy to filter these out, except >>> that we would need to know how common and tolerated this is today among

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

On Thursday, November 10, 2022 8:32:16 AM EST Steve Atkins wrote: > > 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

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

On Thu 10/Nov/2022 14:32:16 +0100 Steve Atkins wrote: The other (more common?) case is that the original recipient is in the signed 822.To, while the new recipient is not in the To: or Cc: headers at all. While that’s just the same as old-school alias forwarding, and you might not be able to

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

On Thursday, November 10, 2022 7:54:25 AM EST Murray S. Kucherawy wrote: > On Thu, Nov 10, 2022 at 12:42 PM Scott Kitterman > > wrote: > > I agree that we don't want too much detail in the charter about the > > technical > > nature of the problem, but I would like to understand it in more detail

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

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

> On 10 Nov 2022, at 13:24, Murray S. Kucherawy wrote: > > [offlist] > > On Thu, Nov 10, 2022 at 1:21 PM Laura Atkins > wrote: > >> On 10 Nov 2022, at 13:17, Murray S. Kucherawy > > wrote: >> >> On Thu, Nov 10, 2022 at 12:54 PM

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

On Thu, Nov 10, 2022 at 1:24 PM Murray S. Kucherawy wrote: > [offlist] > > ... > Actually I didn't intend for it to be offlist, sorry for the confusing tag. -MSK ___ Ietf-dkim mailing list Ietf-dkim@ietf.org

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

[offlist] On Thu, Nov 10, 2022 at 1:21 PM Laura Atkins wrote: > > 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

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

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

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 enough > that the sender couldn’t maintain an account there long enough to send out > any volume of

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

> On 10 Nov 2022, at 12:42, Scott Kitterman wrote: > > I agree that we don't want too much detail in the charter about the technical > nature of the problem, but I would like to understand it in more detail in > order to better assess the appropriateness of what is there. > > If a domain is

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

On Thu, Nov 10, 2022 at 12:42 PM Scott Kitterman wrote: > I agree that we don't want too much detail in the charter about the > technical > nature of the problem, but I would like to understand it in more detail in > order to better assess the appropriateness of what is there. > > If a domain is

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

I agree that we don't want too much detail in the charter about the technical nature of the problem, but I would like to understand it in more detail in order to better assess the appropriateness of what is there. If a domain is signing spam and their reputation suffers as a result, isn't that

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

We could add a sentence or two that says we’re seeing increasing spam campaigns that use DKIM replay to get their spam sent out, taking advantage of — and subsequently damaging — the reputation of the domain that signed the original message. Do you think that would be useful? More detail than

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

I think having a precised understanding of the problem that the charter is meant to address is important. I am having a hard time finding a technical distinction between a "replay attack" and the, by design, nature of DKIM's independence from transport details. I have not read all the drafts,

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

Is this relevant to the charter? Do you doubt the attacks sufficiently that you would want to object to chartering a working group to address the issue? Barry On Wed, Nov 9, 2022 at 4:54 PM Alessandro Vesely wrote: > > On Wed 09/Nov/2022 13:08:15 +0100 Barry Leiba wrote: > > > > [...] > > > >

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

On Wed 09/Nov/2022 13:08:15 +0100 Barry Leiba wrote: [...] Current proposals include the following drafts: - draft-bradshaw-envelope-validation-extension-dkim - draft-chuang-replay-resistant-arc - draft-gondwana-email-mailpath - draft-kucherawy-dkim-anti-replay The working group will