Re: [Ietf-dkim] Proposals for tolerating mailing list modifications
By all means, let's make this a cesspool of irrelevant junk. Especially for junk that clearly has no clue about the history of DKIM. A sustained pattern of aggressively hostile postings creates a hostile work environment. Simply repeatedly warning against such behavior is obviously not effective. 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] Proposals for tolerating mailing list modifications
On 8/5/23 9:05 AM, Murray S. Kucherawy wrote: On Fri, Aug 4, 2023 at 2:46 PM Michael Thomas wrote: Well, for starters ARC doesn't have broad deployment. But the author doesn't say why ARC is needed or relevant. That is the point here. *All* changes need to be justified including any imported mechanisms. The less rat holes the better. Same with the mailing list modification draft. Why is that even relevant? With respect to ARC: There's a difference between asking for justification and demanding that the discussion be stopped before it even starts. One of those is not okay. Ok, justify it. Even the author says ARC brings nothing to the table. That is not OK. Peddle the ARC agenda in a more appropriate venue. With respect to the MLM draft: Since this is the only IETF list that covers DKIM specifically, that makes it a reasonable venue for raising DKIM-related ideas that might exceed the charter. I would agree that this WG shouldn't take up any DKIM topics not related to the replay problem, but I don't see an issue with announcing in this venue that you have an idea and invite discussion off-list or in some other venue for as long as this list is allocated to an active working group. By all means, let's make this a cesspool of irrelevant junk. Especially for junk that clearly has no clue about the history of DKIM. Mike ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Proposals for tolerating mailing list modifications
On Fri, Aug 4, 2023 at 2:46 PM Michael Thomas wrote: > Well, for starters ARC doesn't have broad deployment. But the author > doesn't say why ARC is needed or relevant. That is the point here. *All* > changes need to be justified including any imported mechanisms. The less > rat holes the better. Same with the mailing list modification draft. Why is > that even relevant? > With respect to ARC: There's a difference between asking for justification and demanding that the discussion be stopped before it even starts. One of those is not okay. With respect to the MLM draft: Since this is the only IETF list that covers DKIM specifically, that makes it a reasonable venue for raising DKIM-related ideas that might exceed the charter. I would agree that this WG shouldn't take up any DKIM topics not related to the replay problem, but I don't see an issue with announcing in this venue that you have an idea and invite discussion off-list or in some other venue for as long as this list is allocated to an active working group. -MSK, ART AD ___ 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 5 Aug 2023, at 02:43, Jesse Thompson wrote: > > On Thu, Aug 3, 2023, at 11:08 AM, Laura Atkins wrote: >> 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. > > I'll be there and interesting in participating. As an ESP/infrastructure > provider I can say that we are "having" the issue, but can't say that we > "seeing" the issue since visibility is only available to anti-spammers, and > domain owners (who receive DMARC reports). A big driver of the work is actually Google. As I understand it, they are having issues because the replay attackers are successfully stealing reputation of otherwise good senders in order to bypass some spam filtering. The replay attackers aren’t sending what we commonly think of as spam through the signers - as the message is sent to one recipient (not bulk) and it is opt-in (that recipient wants and has asked for the mail). > I recall various assertions that the reason why DMARC has been successful is > primarily because of the Reporting benefits (and I certainly agree with this > assertion from my background as an enterprise domain owner), while the > Conformance benefits seem to be more elusive (as evidenced by the > inconsistent adoption by receivers and the debates around interoperability > issues with indirect mail streams). Of course, the Authentication benefits > are provided by DKIM/SPF, and yet DKIM signers have no standard mechanism to > receive reports of how their signatures are being misused. > > If people think that Reporting is the reason why DMARC has been successful, > then could we conclude that the lack of Reporting to DKIM signers is a > problem worth addressing? That’s an interesting thought. I’m thinking the next step down - will it help minimize the problem for senders? ie, would reporting be fast enough that they could revoke a key? What might a report look like? laura -- 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
