Re: [Ietf-dkim] Call for adoption results: draft-ietf-dkim-replay-problem Adopted
On Thu, Aug 3, 2023 at 10:01 AM Suresh Ramasubramanian wrote: > Would this effort be better targeted at the various open source as well as > proprietary implementations of DKIM libraries, to flag if not eliminate the > various edge cases that are being gamed by the spammers? > > > > Rolling out software with a sane set of configuration defaults would > typically mean that they’d be baked into production implementations, that’d > put considerable thought into overriding any such default setting > What sort of changes do you have in mind? -MSK, participating ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Call for adoption results: draft-ietf-dkim-replay-problem Adopted
Would this effort be better targeted at the various open source as well as proprietary implementations of DKIM libraries, to flag if not eliminate the various edge cases that are being gamed by the spammers? Rolling out software with a sane set of configuration defaults would typically mean that they’d be baked into production implementations, that’d put considerable thought into overriding any such default setting From: Ietf-dkim on behalf of Barry Leiba Date: Thursday, 3 August 2023 at 9:15 PM To: dcroc...@bbiw.net Cc: ietf-dkim@ietf.org Subject: Re: [Ietf-dkim] Call for adoption results: draft-ietf-dkim-replay-problem Adopted > A point I was trying to make in earlier posts is that this topic does > not seem to me to warrant anything close to that much effort on > producing background text. > > Especially when we so far seem to be lacking cohesive effort to > formulate serious technical and operational 'solutions' and the > community support to field them. > > We need a lot more focus on the recruiting industry > support/participation and on formulating technical specifications that > will be used. This I completely agree with: we saw a great deal of interest from M3AAWG about this, and the discussions there led to discussions here that got this working group started. But since then we've seen no apparent interest in following through, apart from the few who actively drove the chartering. I agree that we need to see broader interest in working on solutions and broad assurance that those solutions will be implemented. There's been talk about having a session at the October M3AAWG meeting in New York, and I'll be interested to see what results from that. Barry ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Call for adoption results: draft-ietf-dkim-replay-problem Adopted
> On 3 Aug 2023, at 16:44, Barry Leiba wrote: > >> A point I was trying to make in earlier posts is that this topic does >> not seem to me to warrant anything close to that much effort on >> producing background text. >> >> Especially when we so far seem to be lacking cohesive effort to >> formulate serious technical and operational 'solutions' and the >> community support to field them. >> >> We need a lot more focus on the recruiting industry >> support/participation and on formulating technical specifications that >> will be used. > > This I completely agree with: we saw a great deal of interest from > M3AAWG about this, and the discussions there led to discussions here > that got this working group started. But since then we've seen no > apparent interest in following through, apart from the few who > actively drove the chartering. I agree that we need to see broader > interest in working on solutions and broad assurance that those > solutions will be implemented. There's been talk about having a > session at the October M3AAWG meeting in New York, and I'll be > interested to see what results from that. I agree with this and have been working to recruit folks to come here. I’ll also be in Brooklyn and pitching the need for participation in the IETF working group from folks in the email space who are seeing issues with this. laura (participating) -- The Delivery Expert Laura Atkins Word to the Wise la...@wordtothewise.com Delivery hints and commentary: http://wordtothewise.com/blog ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Call for adoption results: draft-ietf-dkim-replay-problem Adopted
> A point I was trying to make in earlier posts is that this topic does > not seem to me to warrant anything close to that much effort on > producing background text. > > Especially when we so far seem to be lacking cohesive effort to > formulate serious technical and operational 'solutions' and the > community support to field them. > > We need a lot more focus on the recruiting industry > support/participation and on formulating technical specifications that > will be used. This I completely agree with: we saw a great deal of interest from M3AAWG about this, and the discussions there led to discussions here that got this working group started. But since then we've seen no apparent interest in following through, apart from the few who actively drove the chartering. I agree that we need to see broader interest in working on solutions and broad assurance that those solutions will be implemented. There's been talk about having a session at the October M3AAWG meeting in New York, and I'll be interested to see what results from that. Barry ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Call for adoption results: draft-ietf-dkim-replay-problem Adopted
On 8/3/2023 1:46 AM, Laura Atkins wrote: Put together a background document - that evolves from the problem statement including all the pieces that you mentioned There are topics and times when this much effort, for a document covering background issues, makes sense. However producing such a document, especially going through RFC publication processes, is extremely expensive. A point I was trying to make in earlier posts is that this topic does not seem to me to warrant anything close to that much effort on producing background text. Especially when we so far seem to be lacking cohesive effort to formulate serious technical and operational 'solutions' and the community support to field them. We need a lot more focus on the recruiting industry support/participation and on formulating technical specifications that will be used. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net mast:@dcrocker@mastodon.social ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Call for adoption results: draft-ietf-dkim-replay-problem Adopted
> On 1 Aug 2023, at 17:00, Dave Crocker wrote: > > On 8/1/2023 8:56 AM, Barry Leiba wrote: >> The eventual product should point back to the problem statement for >> the background information. > > That is certainly a valid approach. However I suggest it's less efficient > for this topic and possibly will lose some casual readers of the spec, by > virtue of the indirection. (Extra clicks cost usability.) I’m not sure this is a problem, actually. It’s likely we’ll lose those casual readers anyway, if they’re bogged down in background information. > I suggest, instead, whatever spec is produced have a statement of the > problem. This is a relatively simple problem to explain. No doubt the text > will be drawn from this draft. Of course the spec will have a statement of the problem. The question here is: how much does the spec focus on the spec vs. how much does it discuss all the examples and data about why we got to this as the spec. I think that the why, condensed down in a supporting document, is valuable. I think, though, that as part of the spec it’s a distraction. laura (participating) -- The Delivery Expert Laura Atkins Word to the Wise la...@wordtothewise.com Delivery hints and commentary: http://wordtothewise.com/blog ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Call for adoption results: draft-ietf-dkim-replay-problem Adopted
I actually think this is a good approach and works well within the charter that we have for the group. Put together a background document - that evolves from the problem statement including all the pieces that you mentioned * problem description * why this wasn’t solved initially * real world scenarios where this happens and some of the consequences of it backed by actual data * what has been tried and hasn’t worked (with some discussion of why it didn’t work) * what we considered and rejected In fact, I think that’s one of the legitimate outcomes of the group from the re-charter (https://datatracker.ietf.org/wg/dkim/about/): "If the working group decides that is unable to identify a consensus technical solution to this problem space, it may instead publish a report describing the problem and summarizing the reasons that none of the proposed approaches are acceptable.” laura (as participant) > On 1 Aug 2023, at 19:40, Barry Leiba wrote: > > As someone who has, as an AD, questioned the publication of such > background documents, even in working groups I chartered, I can give a > related opinion about this one: > > I do think the background is important to publish separately for this > work, however easy the problem is to describe. I think it's important > that those interested have access to the problem description, reasons > that it wasn't solved in the original DKIM specification, things that > people have tried and that didn't work, and things that we have > considered and rejected, and any other such background that got us to > where we are now and that eventually gets us to what we propose, if, > indeed, we wind up proposing anything. And I think it's important > *not* to put that into any protocol proposal that we make, so as to > keep that specification clean and concise. > > Yes, we *could* put it into a protocol document as an appendix, but I > think in this case it could be longer than the protocol description > and will likely bloat the document and be distracting. I would rather > see something that that gives a one-paragraph summary of what we're > solving, a reference to the document with the broader background, the > proposed solution, and whatever limitations and cautions we see for > that solution. > > That said, this'll be my last opinion on that point, as I don't think > it's worth a great deal of debate and I'm happy to accept whatever > consensus we wind up with. Better to spend the effort on the > solution. > > Barry > > On Tue, Aug 1, 2023 at 1:30 PM Murray S. Kucherawy > wrote: >> >> On Tue, Aug 1, 2023 at 8:29 AM Laura Atkins wrote: >>> >>> We have a current version of the draft problem statement available on the >>> data tracker. Murray and a few others made a few comments that were added >>> in the -03 version. >>> >>> >>> https://mailarchive.ietf.org/arch/msg/ietf-dkim/Q5ybHiYkMlg5QFaFp28Y8uSme1Q/ >>> >>> >>> Based on discussions, there seems to be favor to documenting what has been >>> tried and not worked. >>> >>> >>> Question for the working group: Should the discussion of what hasn’t worked >>> be in the problem statement as an Appendix? Or should it be in a separate >>> document as working group output? >>> >>> >>> Along the same lines, do members of the working group feel we should >>> include some of the solution space in the problem statement? Or should the >>> discussion be reworked? >>> >>> >>> Perhaps instead of "possible solution space" maybe "scenarios and how they >>> affect dkim replay" ? We welcome any suggestions of wording changes. >> >> >> I just did an informal poll of the IESG members that happened to be active >> in the IESG slack channel at the time I asked. >> >> There's a previous IESG statement on this topic that's relevant: >> https://www.ietf.org/about/groups/iesg/statements/support-documents/ >> >> Generally, this informal poll suggests the IESG disfavors a document that is >> nothing more than a problem statement. This aligns, unsurprisingly, with >> the IESG statement. Such documents, by themselves, have uncertain archival >> value. So if we want to publish a problem statement, with or without a >> "what we've tried" appendix, we should consider merging the proposed >> solution(s) into such a document before advancing it to the IESG. >> >> -MSK, ART AD >> ___ >> Ietf-dkim mailing list >> Ietf-dkim@ietf.org >> https://www.ietf.org/mailman/listinfo/ietf-dkim -- The Delivery Expert Laura Atkins Word to the Wise la...@wordtothewise.com Delivery hints and commentary: http://wordtothewise.com/blog ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Tolerating Mailing-List Modifications I-D
Dude. This is so 20 years ago. It only gets you so far. I should know. There is nothing for IETF to do here. The basic tools are already available in DKIM to do this. It's up to individual sites to determine their own tolerance to changes and that's nothing the IETF has any say over. And it most certainly has nothing to do with ARC. There is nothing here for IETF to standardize. Whatsoever. When it wanders into heuristic land it ceases to be an IETF problem. The only thing IETF can do is facilitate that experiment. It already has. Mike ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
