Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

On 2/17/23 4:51 PM, Evan Burke wrote: On Fri, Feb 17, 2023 at 9:49 AM Michael Thomas wrote: Which brings up another question which is applicable to the problem statement: are mailbox providers like gmail, hotmail, etc getting abused from these replays? Some spam from

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

On Sun, Feb 19, 2023 at 11:49 AM Dave Crocker wrote: > This is a very basic point about protocols vs. implementations. A > protocol defines the 4 walls of its sandbox. It owns that sandbox and > defines whatever it needs to, within the confines of that space. > > [...] > > But again, this is

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

The RFC just talks about returning PERFMAIL when the evaluation fails for one reason or another.  It's abstract, of course; the implementer is free to decide what that actually means in each case.  In the implementation I did, the library receives all the details and returns a status (with

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

On 2/18/23 8:41 PM, Murray S. Kucherawy wrote: On Sat, Feb 18, 2023 at 8:27 PM Michael Thomas wrote: Beyond this SHOULD, I think we need to consider whether the caller needs to be told specifically when a failure occurs for this reason.  Right now an implementation

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

On Sat, Feb 18, 2023 at 8:27 PM Michael Thomas wrote: > > >> Beyond this SHOULD, I think we need to consider whether the caller needs >> to be told specifically when a failure occurs for this reason. Right now >> an implementation might return just a PERMFAIL without noting that it's >> because

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

On 2/18/23 8:13 PM, Murray S. Kucherawy wrote: On Sat, Feb 18, 2023 at 12:10 PM Michael Thomas wrote: Beyond this SHOULD, I think we need to consider whether the caller needs to be told specifically when a failure occurs for this reason.  Right now an implementation might

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

On Sat, Feb 18, 2023 at 12:10 PM Michael Thomas wrote: > > > Beyond this SHOULD, I think we need to consider whether the caller needs > to be told specifically when a failure occurs for this reason. Right now > an implementation might return just a PERMFAIL without noting that it's > because of

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

On 2/17/23 5:02 PM, Murray S. Kucherawy wrote: On Fri, Feb 17, 2023 at 9:35 AM Scott Kitterman wrote: Currently RFC 6376 says, "Signatures MAY be considered invalid".  I think the practical effect as described in protocol terms would be to change the MAY to SHOULD under X

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

100% agree. If this is the path we decide to go down, we can't really change the protocol for this. It's advice on when/why to deal with X in a particular way. Perhaps I was overly subtle, but that's why I described it as the practical effect. I didn't mean to suggest a protocol change.

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

On 2/18/23 11:52 AM, Barry Leiba wrote: I think that changing this to SHOULD is the wrong approach. An Applicability Statement might well give advice, possibly at the SHOULD level, that goes beyond this and discusses use cases, but the base protocol uses MAY for a good reason, and at the

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

I think that changing this to SHOULD is the wrong approach. An Applicability Statement might well give advice, possibly at the SHOULD level, that goes beyond this and discusses use cases, but the base protocol uses MAY for a good reason, and at the protocol level it should stay that way. Barry

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

On Fri, Feb 17, 2023 at 9:35 AM Scott Kitterman wrote: > Currently RFC 6376 says, "Signatures MAY be considered invalid". I think > the practical effect as described in protocol terms would be to change the > MAY to SHOULD under X conditions and SHOULD NOT under !X conditions. Not > that I'd

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

On Fri, Feb 17, 2023 at 9:49 AM Michael Thomas wrote: > > Which brings up another question which is applicable to the problem > statement: are mailbox providers like gmail, hotmail, etc getting abused > from these replays? Some spam from whokn...@hotmail.com doesn't seem > like a very good

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

On 2/17/23 9:34 AM, Scott Kitterman wrote: Currently RFC 6376 says, "Signatures MAY be considered invalid". I think the practical effect as described in protocol terms would be to change the MAY to SHOULD under X conditions and SHOULD NOT under !X conditions. Not that I'd expect to see

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

Currently RFC 6376 says, "Signatures MAY be considered invalid". I think the practical effect as described in protocol terms would be to change the MAY to SHOULD under X conditions and SHOULD NOT under !X conditions. Not that I'd expect to see this appear in a protocol document (maybe some

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

On Thu, Feb 16, 2023 at 2:13 PM Barry Leiba wrote: > I like this approach: if the issue is that an "expired" signature is > treated as unsigned, I think we have an unacceptable level of false > positives. But if the fact that a signature is valid but expired is > simply another factor in the

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

On Thu 16/Feb/2023 21:56:52 +0100 Barry Leiba wrote: Okay. What's the value for X - T that prevents this problem, but doesn't cause DKIM signatures of "normal" mail to fail? There's not one "right" value; we're talking about distributions of timings for normal mail vs. replay, and yes,

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

On Thu, Feb 16, 2023 at 3:32 PM Dave Crocker wrote: > On 2/16/2023 3:23 PM, Jeremy Harris wrote: > > Does that not assume that the point where a message is held during > > delay is after the point of signing? > > Yes, because it often and maybe nearly always is. Even a single site > can have

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

On 2/16/2023 3:23 PM, Jeremy Harris wrote: Does that not assume that the point where a message is held during delay is after the point of signing? Yes, because it often and maybe nearly always is.  Even a single site can have multiple 'points' where processing of a message happens. 

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

On 16/02/2023 23:17, Dave Crocker wrote: On 2/16/2023 2:04 PM, Evan Burke wrote: 1hr is at the very low end of the scale, only appropriate in narrow, specific circumstances. I think you're right that 2+ days is the right range for most mail. The historical common choice, for when to stop

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

On 2/16/2023 2:04 PM, Evan Burke wrote: 1hr is at the very low end of the scale, only appropriate in narrow, specific circumstances. I think you're right that 2+ days is the right range for most mail. The historical common choice, for when to stop retrying mail delivery, has been 3 days. 

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

This could apply to other things like over some rate limit threshold or the reputation based approach I suggested as well. The key thing that's relevant to the problem statement is that the problem is how the reputation impact of the signature is applied, not signature continues to validate

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

I like this approach: if the issue is that an "expired" signature is treated as unsigned, I think we have an unacceptable level of false positives. But if the fact that a signature is valid but expired is simply another factor in the decision, I think we might be OK, keeping in mind that "x=" is

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

On Thu, Feb 16, 2023 at 12:57 PM Barry Leiba wrote: > >> Okay. What's the value for X - T that prevents this problem, but > doesn't cause DKIM signatures of "normal" mail to fail? > > > > There's not one "right" value; we're talking about distributions > > of timings for normal mail vs. replay,

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

On February 16, 2023 9:21:51 PM UTC, Michael Thomas wrote: > >On 2/16/23 12:56 PM, Barry Leiba wrote: Okay. What's the value for X - T that prevents this problem, but doesn't cause DKIM signatures of "normal" mail to fail? >>> There's not one "right" value; we're talking about

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

On 2/16/23 12:56 PM, Barry Leiba wrote: Okay. What's the value for X - T that prevents this problem, but doesn't cause DKIM signatures of "normal" mail to fail? There's not one "right" value; we're talking about distributions of timings for normal mail vs. replay, and yes, there's some

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

There's not one "right" value; we're talking about distributions of timings for normal mail vs. replay, and yes, there's some overlap there. ... I understand the pushback; this is a list to talk about a standard, and standards tend to be a lot more binary in their functionality, Glad to

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

>> Okay. What's the value for X - T that prevents this problem, but doesn't >> cause DKIM signatures of "normal" mail to fail? > > There's not one "right" value; we're talking about distributions > of timings for normal mail vs. replay, and yes, there's some > overlap there. In practice I've

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

On February 16, 2023 8:03:01 PM UTC, Evan Burke wrote: >On Thu, Feb 16, 2023 at 10:45 AM Scott Kitterman >wrote: > >> >> On February 16, 2023 6:10:39 PM UTC, Evan Burke > 40mailchimp@dmarc.ietf.org> wrote: >> >The biggest current problem with replay is that it happens in bulk, at >>

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

On Thu, Feb 16, 2023 at 10:45 AM Scott Kitterman wrote: > > On February 16, 2023 6:10:39 PM UTC, Evan Burke 40mailchimp@dmarc.ietf.org> wrote: > >The biggest current problem with replay is that it happens in bulk, at > >substantial scale. x= is effective against that because it takes time

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

On February 16, 2023 6:10:39 PM UTC, Evan Burke wrote: >On Thu, Feb 16, 2023 at 7:30 AM Murray S. Kucherawy >wrote: > >> >> If my prior formulation is right, i.e., that the attack only takes a few >> seconds to complete, what "x=" value are we proposing that will work here >> without also

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

On Thu, Feb 16, 2023 at 7:30 AM Murray S. Kucherawy wrote: > > If my prior formulation is right, i.e., that the attack only takes a few > seconds to complete, what "x=" value are we proposing that will work here > without also bringing undesirable side effects? > > The biggest current problem

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

On 2/16/2023 2:39 AM, Laura Atkins wrote: The flip side of that is that spammers are not equal opportunity: they target the large consumer mailbox providers. So if the problem only affects groups that are this tall, then a solution that fixes it for those providers might be reasonable. This

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

On Wed, Feb 15, 2023 at 10:49 PM Evan Burke wrote: > >> I don't think we're saying different things. I remember the point of the >> answer I got in that session being that most, but not all, implementations >> check or enforce signature expiration. But that means if "x=" is the >> solution we

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

> On 16 Feb 2023, at 04:16, Murray S. Kucherawy wrote: >> >> There are *tons* of external dependencies on the filtering MTA. I really >> can't imagine that this would be the straw that breaks the camel's >> back. > > Depends (as I think Scott said) on the size and resources available

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

On Wed, Feb 15, 2023 at 8:16 PM Murray S. Kucherawy wrote: > On Wed, Feb 15, 2023 at 2:21 PM Michael Thomas wrote: > >> >> There's also the question of whether "x=" is properly enforced. RFC 6376 >> says verifiers "MAY" choose to enforce it. I think I asked about this at a >> conference

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

On Wed, Feb 15, 2023 at 2:21 PM Michael Thomas wrote: > > There's also the question of whether "x=" is properly enforced. RFC 6376 > says verifiers "MAY" choose to enforce it. I think I asked about this at a > conference recently and was told that it's not universally supported by >

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

On February 15, 2023 10:18:50 PM UTC, "Murray S. Kucherawy" wrote: >On Wed, Feb 15, 2023 at 5:39 AM Scott Kitterman >wrote: > >> Any reputation based solution does have down scale limits. Small mail >> sources >> (such as your random Nebraska forwarder) generally will have no reputation >>

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

On 2/15/23 2:12 PM, Murray S. Kucherawy wrote: On Tue, Feb 14, 2023 at 11:44 AM Michael Thomas wrote: At maximum, isn't it just the x= value? It seems to me that if you don't specify an x= value, or it's essentially infinite, they are saying they don't care about "replays". Which

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

On Wed, Feb 15, 2023 at 5:39 AM Scott Kitterman wrote: > Any reputation based solution does have down scale limits. Small mail > sources > (such as your random Nebraska forwarder) generally will have no reputation > vice a negative one and so wouldn't get penalized in a scheme like the one > I

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

On Tue, Feb 14, 2023 at 11:44 AM Michael Thomas wrote: > At maximum, isn't it just the x= value? It seems to me that if you don't > specify an x= value, or it's essentially infinite, they are saying they > don't care about "replays". Which is fine in most cases and you can just > ignore it.

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

On Wednesday, February 15, 2023 5:23:34 AM EST Alessandro Vesely wrote: > On Tue 14/Feb/2023 23:42:36 +0100 Scott Kitterman wrote: > > On Tuesday, February 14, 2023 4:16:00 PM EST Evan Burke wrote: > >> On Tue, Feb 14, 2023 at 11:44 AM Michael Thomas wrote: > >>> On Tue, Feb 14, 2023 at 11:18 AM

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

On Tue 14/Feb/2023 23:42:36 +0100 Scott Kitterman wrote: On Tuesday, February 14, 2023 4:16:00 PM EST Evan Burke wrote: On Tue, Feb 14, 2023 at 11:44 AM Michael Thomas wrote: On Tue, Feb 14, 2023 at 11:18 AM Michael Thomas wrote: Have you considered something like rate limiting on the

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

On Tuesday, February 14, 2023 4:16:00 PM EST Evan Burke wrote: > On Tue, Feb 14, 2023 at 11:44 AM Michael Thomas wrote: > > On Tue, Feb 14, 2023 at 11:18 AM Michael Thomas wrote: > >> Have you considered something like rate limiting on the receiver side for > >> things with duplicate msg-id's?

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

On 2/14/23 1:16 PM, Evan Burke wrote: On Tue, Feb 14, 2023 at 11:44 AM Michael Thomas wrote: On Tue, Feb 14, 2023 at 11:18 AM Michael Thomas wrote: Have you considered something like rate limiting on the receiver side for things with duplicate msg-id's? Aka, a tar

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

On Tue, Feb 14, 2023 at 11:44 AM Michael Thomas wrote: > On Tue, Feb 14, 2023 at 11:18 AM Michael Thomas wrote: > >> Have you considered something like rate limiting on the receiver side for >> things with duplicate msg-id's? Aka, a tar pit, iirc? >> > I believe Yahoo does currently use some

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

On 2/14/23 11:30 AM, Murray S. Kucherawy wrote: On Tue, Feb 14, 2023 at 11:18 AM Michael Thomas wrote: Have you considered something like rate limiting on the receiver side for things with duplicate msg-id's? Aka, a tar pit, iirc? As I recall that technique is sometimes not

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

On Tue, Feb 14, 2023 at 11:18 AM Michael Thomas wrote: > Have you considered something like rate limiting on the receiver side for > things with duplicate msg-id's? Aka, a tar pit, iirc? > As I recall that technique is sometimes not suggested because (a) we can't come up with good advice about

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

On 2/13/23 9:43 PM, Evan Burke wrote: On Fri, Feb 10, 2023 at 2:31 PM Michael Thomas wrote: On 2/10/23 2:10 PM, Evan Burke wrote: The M3AAWG BCP will cover recommended header signing/oversigning policies. I'll make sure that's shared here when it's published. Any idea

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

On Tue 14/Feb/2023 06:43:22 +0100 Evan Burke wrote: On Fri, Feb 10, 2023 at 2:31 PM Michael Thomas wrote: On 2/10/23 2:10 PM, Evan Burke wrote: The M3AAWG BCP will cover recommended header signing/oversigning policies. I'll make sure that's shared here when it's published. Any idea when

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

On Fri, Feb 10, 2023 at 2:31 PM Michael Thomas wrote: > On 2/10/23 2:10 PM, Evan Burke wrote: > > The M3AAWG BCP will cover recommended header signing/oversigning policies. > I'll make sure that's shared here when it's published. > > Any idea when that might drop? > I'll roughly summarize the

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

On Mon, Feb 13, 2023 at 10:42 AM Michael Thomas wrote: > > On 2/13/23 2:49 AM, Laura Atkins wrote: > > > > Basically saying if you're not filtering outbound mail for abuse, > > you're part of the problem. > > > > I don’t see how that’s relevant to the discussion here. > It's extremely relevant.

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

On 2/13/23 2:49 AM, Laura Atkins wrote: Basically saying if you're not filtering outbound mail for abuse, you're part of the problem. I don’t see how that’s relevant to the discussion here. It's extremely relevant. If you don't want to be viewed as a spamming domain, do your part to not

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

> On 12 Feb 2023, at 21:49, Michael Thomas wrote: > > > > On 2/12/23 1:34 PM, Murray S. Kucherawy wrote: >> On Fri, Feb 10, 2023 at 2:13 PM Michael Thomas > > wrote: >> Another thing that should probably be discussed is outbound spam filtering. >> At a high level, this

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

On 2/10/23 3:11 PM, Michael Thomas wrote: On 2/10/23 10:23 AM, Wei Chuang wrote: | resign for DKIM on behalf of the Originator though the | Originator increases risk of losing control of their private key. I'm pretty sure that the best practice here is to just create a selector(s) for the

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

On 2/12/23 12:15 AM, Wei Chuang wrote: Consolidating the new points raised and my replies: On Fri, Feb 10, 2023 Michael Thomas wrote: Another thing that should probably be discussed is outbound spam filtering. At a high level, this is really about the sender sending spam. But

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

On 2/12/23 1:34 PM, Murray S. Kucherawy wrote: On Fri, Feb 10, 2023 at 2:13 PM Michael Thomas wrote: Another thing that should probably be discussed is outbound spam filtering. At a high level, this is really about the sender sending spam. But email afaik is silent on whether

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

On Fri, Feb 10, 2023 at 2:13 PM Michael Thomas wrote: > Another thing that should probably be discussed is outbound spam > filtering. At a high level, this is really about the sender sending spam. > But email afaik is silent on whether senders or receivers should filter for > spam (and if there

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

Consolidating the new points raised and my replies: On Fri, Feb 10, 2023 Michael Thomas wrote: Another thing that should probably be discussed is outbound spam filtering. At a high level, this is really about the sender sending spam. But email afaik is silent on whether senders or receivers

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

On 2/10/23 9:36 PM, Murray S. Kucherawy wrote: On Fri, Feb 10, 2023 at 12:06 PM Evan Burke wrote: On Fri, Feb 10, 2023 at 11:47 AM Dave Crocker wrote: On 2/10/2023 11:35 AM, Wei Chuang wrote: > ARC is a tool to help support modern Indirect Mail Flows, and I

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

On Fri, Feb 10, 2023 at 12:06 PM Evan Burke wrote: > > On Fri, Feb 10, 2023 at 11:47 AM Dave Crocker wrote: > >> On 2/10/2023 11:35 AM, Wei Chuang wrote: >> > ARC is a tool to help support modern Indirect Mail Flows, and I >> > believe belongs in the solution space to be explored. >> >> Since

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

On 2/10/23 10:23 AM, Wei Chuang wrote: Hi all, I've posted an updated version of the draft-chuang-dkim-replay-problem-01 draft.  It cleans up a lot from the -00 rough draft state so hopefully it's more clear.  It builds

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

On 2/10/23 10:23 AM, Wei Chuang wrote: | resign for DKIM on behalf of the Originator though the | Originator increases risk of losing control of their private key. I'm pretty sure that the best practice here is to just create a selector(s) for the ESP's, etc, signing keys. You definitely

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

On 2/10/23 10:23 AM, Wei Chuang wrote: [] SPF authentication is possible, but may not be advisable. The Originator does this by publishing an SPF policy that covers the Outbound Filtering Service IPs but this IP sharing weakens authentication. Why do you say it weakens it? Isn't it pretty

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

On 2/10/23 2:10 PM, Evan Burke wrote: On Fri, Feb 10, 2023 at 1:55 PM Michael Thomas wrote: | taking advantage of the flexibility in DKIM to | selectively sign headers, the spammer may intentionally leave out | certain headers such as To:, and Subject: that can be

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

On 2/10/23 2:11 PM, Wei Chuang wrote: On Fri, Feb 10, 2023 at 1:48 PM Michael Thomas wrote: | When large amounts of spam are received by the mailbox provider, the | operator’s filtering engine will eventually react by dropping the | reputation of the original DKIM signer.

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

On 2/10/23 10:23 AM, Wei Chuang wrote: Hi all, I've posted an updated version of the draft-chuang-dkim-replay-problem-01 draft.  It cleans up a lot from the -00 rough draft state so hopefully it's more clear.  It builds

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

On 2/10/2023 1:47 PM, Wei Chuang wrote: | In addition to being DKIM authenticated via the spoofed DKIM signature ... To be honest I was wondering about that word choice myself. I can change that in the next rev. There is a long-standing misuse of the term spoof, in the anti-abuse

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

On Fri, Feb 10, 2023 at 1:48 PM Michael Thomas wrote: > > On 2/10/23 10:23 AM, Wei Chuang wrote: > > Hi all, > I've posted an updated version of the draft-chuang-dkim-replay-problem-01 > > draft. It cleans up a lot from the

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

On Fri, Feb 10, 2023 at 1:55 PM Michael Thomas wrote: > | taking advantage of the flexibility in DKIM to >> | selectively sign headers, the spammer may intentionally leave out >> | certain headers such as To:, and Subject: that can be added in later >> | without damaging the existing DKIM

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

On 2/10/23 1:48 PM, Wei Chuang wrote: On Fri, Feb 10, 2023 at 1:29 PM Michael Thomas wrote: On 2/10/23 10:23 AM, Wei Chuang wrote: Hi all, I've posted an updated version of the draft-chuang-dkim-replay-problem-01

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

On 2/10/23 1:47 PM, Wei Chuang wrote: On Fri, Feb 10, 2023 at 1:33 PM Michael Thomas wrote: On 2/10/23 10:23 AM, Wei Chuang wrote: Hi all, I've posted an updated version of the draft-chuang-dkim-replay-problem-01

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

On Fri, Feb 10, 2023 at 1:29 PM Michael Thomas wrote: > > On 2/10/23 10:23 AM, Wei Chuang wrote: > > Hi all, > I've posted an updated version of the draft-chuang-dkim-replay-problem-01 > > draft. It cleans up a lot from the

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

On 2/10/23 10:23 AM, Wei Chuang wrote: Hi all, I've posted an updated version of the draft-chuang-dkim-replay-problem-01 draft.  It cleans up a lot from the -00 rough draft state so hopefully it's more clear.  It builds

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

On Fri, Feb 10, 2023 at 1:33 PM Michael Thomas wrote: > > On 2/10/23 10:23 AM, Wei Chuang wrote: > > Hi all, > I've posted an updated version of the draft-chuang-dkim-replay-problem-01 > > draft. It cleans up a lot from the

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

On 2/10/23 10:23 AM, Wei Chuang wrote: Hi all, I've posted an updated version of the draft-chuang-dkim-replay-problem-01 draft.  It cleans up a lot from the -00 rough draft state so hopefully it's more clear.  It builds

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

On 2/10/23 10:23 AM, Wei Chuang wrote: Hi all, I've posted an updated version of the draft-chuang-dkim-replay-problem-01 draft.  It cleans up a lot from the -00 rough draft state so hopefully it's more clear.  It builds

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

On 2/10/2023 12:05 PM, Evan Burke wrote: I realize there are some mixed opinions on ARC, but it's actively used on several of the world's largest email systems - The problem document is not an exercise in politics but an exploration of technical and operational issues. Whether one or

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

On Fri, Feb 10, 2023 at 11:47 AM Dave Crocker wrote: > On 2/10/2023 11:35 AM, Wei Chuang wrote: > > ARC is a tool to help support modern Indirect Mail Flows, and I > > believe belongs in the solution space to be explored. > > Since ARC uses the same technology as DKIM and uses it in pretty much

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

On 2/10/2023 11:35 AM, Wei Chuang wrote: ARC is a tool to help support modern Indirect Mail Flows, and I believe belongs in the solution space to be explored. Since ARC uses the same technology as DKIM and uses it in pretty much the same was, my understanding is that it, too, has the

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

On 2/10/23 11:35 AM, Wei Chuang wrote: On Fri, Feb 10, 2023 at 11:09 AM Michael Thomas wrote: On 2/10/23 10:23 AM, Wei Chuang wrote: Hi all, I've posted an updated version of the draft-chuang-dkim-replay-problem-01

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

On Fri, Feb 10, 2023 at 11:09 AM Michael Thomas wrote: > > On 2/10/23 10:23 AM, Wei Chuang wrote: > > Hi all, > I've posted an updated version of the draft-chuang-dkim-replay-problem-01 > > draft. It cleans up a lot from

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

On 2/10/23 10:23 AM, Wei Chuang wrote: Hi all, I've posted an updated version of the draft-chuang-dkim-replay-problem-01 draft.  It cleans up a lot from the -00 rough draft state so hopefully it's more clear.  It builds

[Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

Hi all, I've posted an updated version of the draft-chuang-dkim-replay-problem-01 draft. It cleans up a lot from the -00 rough draft state so hopefully it's more clear. It builds a case that spammers are exploiting DKIM