Re: [dmarc-ietf] Overall last-call comments on DMARC
Murray S. Kucherawy writes: > Some sort of contract or agreement between sender and receiver > seems to me to be unavoidable if we want to leverage ARC without > having a global domain reputation system. We don't have a > precise method to do that. We need to experiment and > standardize something to that extent, which I hope this WG can > do after publishing -bis. > > I know what "contract" means abstractly, but what does this actually > look like to someone that's looking for specific guidance? The text > you have here, by itself, is vague and I don't think many operators > will know what to do with it. For example Fastmail [1] includes per user account configuration that lists "Forwarding hosts", which affect how they do spam filtering and whether they trust ARC or not (they do have global trusted ARC list also). The M3AAWG forwarding whitepaper will propose that all mailbox providers should include similar setting, i.e., allow users to configure which hosts to trust for ARC. It was already pointed out that forwarding does not happen out of blue, there is always the user setting it up, i.e., joining the mailing list, providing the email address for alumni forwarding etc. When user does that it would also be easy for him to go to the account settings of whatever mailbox provider he uses and add that ARC host there. The mailbox provider could even detect that user is getting emails that are been forwarded and which have ARC headers, and they could even ask similar question they do now when you move mails away from spam folder, i.e., "Not spam", "This email has valid ARC signature for alumni.university.edu, have you configured this organization for forwarding emails to you, and if so do you trust this organization for doing mail authentication checks on behalf of us". What ARC really offers is that if there is ARC header from organization you trust, you can check the ARC-Authentication-Results and use them in addition to your own checks. If for example that header says SPF was pass, and you trust that domain, then you can trust that it properly did SPF checks and you can consider using ARC SPF pass as SPF pass for the email, even when it is now failing. I do not think there will ever be global trusted ARC signers list, as I do for example want to trust certain organizations / countries, and there is no point of me trusting for example microsoft.com ARC signatures, as there should not be forwarders in microsoft that should be forwarding emails to me. If there is ARC header signed by microsoft that header does not have any value for me, but will have some value for some other people. Simiarly I will trust iki.fi (non profit email forwarding service in Finland that will forward all emails I receive to my actual mailbox), but there is no point of you personally to trust iki.fi ARC signatures. Mailbox provides might want to trust iki.fi as one of our 3 members might be using your services, thus adding iki.fi to trusted forwarders makes thins easier for iki.fi members. [1] https://www.fastmail.help/hc/en-us/articles/360060591413-Spam-filtering#forwarding -- kivi...@iki.fi ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] There is no pony, Overall last-call comments on DMARC
My overall assessment as an early adopter and implementation: DMARC SHOULD NOT be declared a Standard Track document. We still have the potential to develop a sound 1st, 3rd party DKIM Policy model. Declaring DMARCBis a STD will only hamper future development. Keep it experimental or informational. DMARC/Bis has represented a big IETF “Elephant In The Room” change in allowing External 3rd Party Organizations to put barriers of entry to correct the IETF protocol development.. Change is needed. DMARCBis is not it. Is there is an Update Document minus the subjectives considerations. It has been a fair process but a very high hurdle to correct a serious IETF protocol problem. All the best, Hector Santos > On Apr 4, 2024, at 4:47 PM, Jim Fenton wrote: > > On 4 Apr 2024, at 13:31, John R. Levine wrote: > >>> I don’t think it’s scope creep at all. The WG charter puts “Review and >>> refinement of the DMARC specification” in phase III, after “Specification >>> of DMARC improvements to support indirect mail flows”. It seems clear to me >>> that standards-track DMARC needs to incorporate those improvements. >>> >>> IESG accepted ARC as an improvement to support indirect mail flows, and I >>> think a complete solution needs to incorporate that. I wish there were >>> better data to support advancing ARC to standards track, and not just from >>> Google (it has to work for smaller players as well). >>> >>> But I am troubled by the possibility that ARC might require domain >>> reputation to avoid ARC header fields supporting From address spoofing. One >>> reason it might work for Google is because they’re big enough to derive >>> their own domain reputation. We’ve not had success with domain reputation >>> at internet scale. >> >> No might about it -- ARC is only useful with domain reputation. Of course, >> DKIM is only useful with domain reputation, as were Domainkeys and IIM, so I >> don't see why it's a problem now. > > Much of the objective of DomainKeys/IIM/DKIM was to provide a reliable domain > identifier that could be used by a reputation system. They avoided saying > that they were doing anything about spam and phishing. OTOH, DMARC is > explicitly saying that it’s there to do something about phishing. > >> We've been going around and around for years now. DMARC works pretty well >> for direct mail flows, so-so for simple indirect flows (forwarders) and >> really badly for mediated indirect flows (mailing lists.) There is nothing >> better than ARC to mitigate those problems and this WG certainly isn't going >> to invent anything now. I agree that at this point we don't have enough >> evidence to advance ARC, so we can punt the question of what or when to do >> with it to MAILMAINT or something. >> >> Our choices are to say here's what DMARC does, it has these problems, here's >> how to use it for the situations where it works, here's how to sort of >> mitigate the ones where it doesn't. Or we can stamp our feet and say DMARC >> is BAD and we will not endorse it and NOBODY should use it, and the rest of >> the mail world will say isn't that cute, the IETF is having a tantrum. > > Or we can say that it’s not ready for standards track yet. The only time I > can think of in this space that we have stamped our feet and said something > is BAD was with ADSP. But I am troubled by the mandatory requirements imposed > by organizations citing an informational RFC, RFC 7489. It makes it seem like > standards track doesn’t mean as much as it should. > > -Jim > > ___ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] There is no pony, Overall last-call comments on DMARC
No might about it -- ARC is only useful with domain reputation. Of course, DKIM is only useful with domain reputation, as were Domainkeys and IIM, so I don't see why it's a problem now. Much of the objective of DomainKeys/IIM/DKIM was to provide a reliable domain identifier that could be used by a reputation system. They avoided saying that they were doing anything about spam and phishing. OTOH, DMARC is explicitly saying that it’s there to do something about phishing. It was totally obvious at the time what DKIM was intended for, so I don't think that's likely to be persuasive. In practice, ARC isn't that bad. IF you're a really big mail system you can collect your own repuations, if you're not so big your users probably subscribe to few enough legit ARC signers that you can manually whitelist them. On my system I think there's about five. It's not like the general spam problem where you have a zillion new identifiers every day most of which are spam but a few are not. Our choices are to say here's what DMARC does, it has these problems, here's how to use it for the situations where it works, here's how to sort of mitigate the ones where it doesn't. Or we can stamp our feet and say DMARC is BAD and we will not endorse it and NOBODY should use it, and the rest of the mail world will say isn't that cute, the IETF is having a tantrum. Or we can say that it’s not ready for standards track yet. The only time I can think of in this space that we have stamped our feet and said something is BAD was with ADSP. But I am troubled by the mandatory requirements imposed by organizations citing an informational RFC, RFC 7489. It makes it seem like standards track doesn’t mean as much as it should. Well, ADSP actually was bad, and DMARC has reinvented much of what was bad about it, but unlike ADSP, it's used by every significant mail system in the world so we're stuck with it. I have heard somewhere that successful standards document actual practice even if the practice is not ideal. It's up to us, we can say nope, not a standard, and people will use it as a standard, or we can say it's not great but here's the standard, and they will use it as a standard. I know which one I'd do. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] There is no pony, Overall last-call comments on DMARC
On 4 Apr 2024, at 13:31, John R. Levine wrote: >> I don’t think it’s scope creep at all. The WG charter puts “Review and >> refinement of the DMARC specification” in phase III, after “Specification of >> DMARC improvements to support indirect mail flows”. It seems clear to me >> that standards-track DMARC needs to incorporate those improvements. >> >> IESG accepted ARC as an improvement to support indirect mail flows, and I >> think a complete solution needs to incorporate that. I wish there were >> better data to support advancing ARC to standards track, and not just from >> Google (it has to work for smaller players as well). >> >> But I am troubled by the possibility that ARC might require domain >> reputation to avoid ARC header fields supporting From address spoofing. One >> reason it might work for Google is because they’re big enough to derive >> their own domain reputation. We’ve not had success with domain reputation at >> internet scale. > > No might about it -- ARC is only useful with domain reputation. Of course, > DKIM is only useful with domain reputation, as were Domainkeys and IIM, so I > don't see why it's a problem now. Much of the objective of DomainKeys/IIM/DKIM was to provide a reliable domain identifier that could be used by a reputation system. They avoided saying that they were doing anything about spam and phishing. OTOH, DMARC is explicitly saying that it’s there to do something about phishing. > We've been going around and around for years now. DMARC works pretty well > for direct mail flows, so-so for simple indirect flows (forwarders) and > really badly for mediated indirect flows (mailing lists.) There is nothing > better than ARC to mitigate those problems and this WG certainly isn't going > to invent anything now. I agree that at this point we don't have enough > evidence to advance ARC, so we can punt the question of what or when to do > with it to MAILMAINT or something. > > Our choices are to say here's what DMARC does, it has these problems, here's > how to use it for the situations where it works, here's how to sort of > mitigate the ones where it doesn't. Or we can stamp our feet and say DMARC > is BAD and we will not endorse it and NOBODY should use it, and the rest of > the mail world will say isn't that cute, the IETF is having a tantrum. Or we can say that it’s not ready for standards track yet. The only time I can think of in this space that we have stamped our feet and said something is BAD was with ADSP. But I am troubled by the mandatory requirements imposed by organizations citing an informational RFC, RFC 7489. It makes it seem like standards track doesn’t mean as much as it should. -Jim ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] There is no pony, Overall last-call comments on DMARC
I don’t think it’s scope creep at all. The WG charter puts “Review and refinement of the DMARC specification” in phase III, after “Specification of DMARC improvements to support indirect mail flows”. It seems clear to me that standards-track DMARC needs to incorporate those improvements. IESG accepted ARC as an improvement to support indirect mail flows, and I think a complete solution needs to incorporate that. I wish there were better data to support advancing ARC to standards track, and not just from Google (it has to work for smaller players as well). But I am troubled by the possibility that ARC might require domain reputation to avoid ARC header fields supporting From address spoofing. One reason it might work for Google is because they’re big enough to derive their own domain reputation. We’ve not had success with domain reputation at internet scale. No might about it -- ARC is only useful with domain reputation. Of course, DKIM is only useful with domain reputation, as were Domainkeys and IIM, so I don't see why it's a problem now. We've been going around and around for years now. DMARC works pretty well for direct mail flows, so-so for simple indirect flows (forwarders) and really badly for mediated indirect flows (mailing lists.) There is nothing better than ARC to mitigate those problems and this WG certainly isn't going to invent anything now. I agree that at this point we don't have enough evidence to advance ARC, so we can punt the question of what or when to do with it to MAILMAINT or something. Our choices are to say here's what DMARC does, it has these problems, here's how to use it for the situations where it works, here's how to sort of mitigate the ones where it doesn't. Or we can stamp our feet and say DMARC is BAD and we will not endorse it and NOBODY should use it, and the rest of the mail world will say isn't that cute, the IETF is having a tantrum. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Overall last-call comments on DMARC
Sender reputation is in use everywhere. What is lacking is an omniscient data source, but I have no hope of finding one. Small senders will always be at a disadvantage because sender reputation is entirely based on past experience, and smaller senders have less experience to draw upon. ARC does not change that dynamic. Forwarding creates two problems: (1) knowing that a forwarding operation occurred, and (2) knowing how I would have dispositioned the message if the forwarding operation had not occurred. ARC helps with both of these. Forwarding tends to hide or discard data, and ARC offsets that data loss. One step in ARC evaluation is determining whether the data provided is sufficient and internally consistent with the rest of the header set. To be fully sufficient, I want to know Mail From address, Helo name, Source IP, and From address at the moment represented by the ARC Set. Without all of this, the ARC set is probably not actionable. With complete data, the ARC set can be matched to a Received header, to check for data consistency. For example, I don't trust a Microsoft ARC set that asserts DKIM Pass for a signature that does not exist. The complete data set also allows me to evaluate how I would have dispositioned the message if it had been received directly, based on the reputations of the prior server, Mail From domain, and From address. Exactly two points of trust come into this process: (a) deciding whether to trust DMARC Pass on a signature that no longer validates, and (b) whether to accept that the internally-consistent data is not a very sophisticated internally-consistent ruse. In the event that I make an incorrect "Allow" decision based on a fraudulent ARC Set, I have to hope that my content filtering will detect and block the attack. But this is nothing new. On a daily basis, I have well-authenticated messages that are malicious and have to be blocked by content filtering. So, I will accept some ARC data, ignore some ARC data, and maybe even block based on some suspicious-looking ARC data. I can only do that if I have the data available to use. Doug Foster On Thu, Apr 4, 2024 at 3:55 PM Jim Fenton wrote: > On 4 Apr 2024, at 12:08, Murray S. Kucherawy wrote: > > > On Thu, Apr 4, 2024 at 12:02 PM Dotzero wrote: > > > >> > >> > >>> > >>> My overall point is that this thread makes it seem like we're not > putting > >>> forward a complete solution. It feels a lot more like a proposed > standard > >>> that for its clear success depends on a bunch of other things that > range > >>> from experimental to abstract to undefined. And if that's a correct > >>> summary, I'm asking if that's what we really want to do. It seems a > little > >>> haphazard, like we're scrambling to tie together the loose ends of a > movie > >>> plot. We need to do a good job of bringing our audience to as solid a > >>> conclusion as possible, or the critics' reviews might not come out > well. > >>> > >> > >> My response to your statement "... this thread makes it seem like we're > >> not putting forward a complete solution." is a complete solution to > what? > >> It seems like people are trying to throw in everything but the kitchen > >> sink, including new proposals and rehashing old issues that were > supposedly > >> settled, as we go through last call. > >> > > > > Yes, that's part of what I'm observing. It's possibly a form of scope > > creep, and indeed "We should stop that" is one valid response. :-) > > I don’t think it’s scope creep at all. The WG charter puts “Review and > refinement of the DMARC specification” in phase III, after “Specification > of DMARC improvements to support indirect mail flows”. It seems clear to me > that standards-track DMARC needs to incorporate those improvements. > > IESG accepted ARC as an improvement to support indirect mail flows, and I > think a complete solution needs to incorporate that. I wish there were > better data to support advancing ARC to standards track, and not just from > Google (it has to work for smaller players as well). > > But I am troubled by the possibility that ARC might require domain > reputation to avoid ARC header fields supporting From address spoofing. One > reason it might work for Google is because they’re big enough to derive > their own domain reputation. We’ve not had success with domain reputation > at internet scale. > > -Jim > > ___ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Overall last-call comments on DMARC
On 4 Apr 2024, at 12:08, Murray S. Kucherawy wrote: > On Thu, Apr 4, 2024 at 12:02 PM Dotzero wrote: > >> >> >>> >>> My overall point is that this thread makes it seem like we're not putting >>> forward a complete solution. It feels a lot more like a proposed standard >>> that for its clear success depends on a bunch of other things that range >>> from experimental to abstract to undefined. And if that's a correct >>> summary, I'm asking if that's what we really want to do. It seems a little >>> haphazard, like we're scrambling to tie together the loose ends of a movie >>> plot. We need to do a good job of bringing our audience to as solid a >>> conclusion as possible, or the critics' reviews might not come out well. >>> >> >> My response to your statement "... this thread makes it seem like we're >> not putting forward a complete solution." is a complete solution to what? >> It seems like people are trying to throw in everything but the kitchen >> sink, including new proposals and rehashing old issues that were supposedly >> settled, as we go through last call. >> > > Yes, that's part of what I'm observing. It's possibly a form of scope > creep, and indeed "We should stop that" is one valid response. :-) I don’t think it’s scope creep at all. The WG charter puts “Review and refinement of the DMARC specification” in phase III, after “Specification of DMARC improvements to support indirect mail flows”. It seems clear to me that standards-track DMARC needs to incorporate those improvements. IESG accepted ARC as an improvement to support indirect mail flows, and I think a complete solution needs to incorporate that. I wish there were better data to support advancing ARC to standards track, and not just from Google (it has to work for smaller players as well). But I am troubled by the possibility that ARC might require domain reputation to avoid ARC header fields supporting From address spoofing. One reason it might work for Google is because they’re big enough to derive their own domain reputation. We’ve not had success with domain reputation at internet scale. -Jim ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Overall last-call comments on DMARC
On Thu, Apr 4, 2024 at 12:02 PM Dotzero wrote: > > >> >> My overall point is that this thread makes it seem like we're not putting >> forward a complete solution. It feels a lot more like a proposed standard >> that for its clear success depends on a bunch of other things that range >> from experimental to abstract to undefined. And if that's a correct >> summary, I'm asking if that's what we really want to do. It seems a little >> haphazard, like we're scrambling to tie together the loose ends of a movie >> plot. We need to do a good job of bringing our audience to as solid a >> conclusion as possible, or the critics' reviews might not come out well. >> > > My response to your statement "... this thread makes it seem like we're > not putting forward a complete solution." is a complete solution to what? > It seems like people are trying to throw in everything but the kitchen > sink, including new proposals and rehashing old issues that were supposedly > settled, as we go through last call. > Yes, that's part of what I'm observing. It's possibly a form of scope creep, and indeed "We should stop that" is one valid response. :-) -MSK, p11g ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Overall last-call comments on DMARC
On Thu, Apr 4, 2024 at 1:42 PM Murray S. Kucherawy wrote: > On Thu, Apr 4, 2024 at 10:21 AM Douglas Foster < > dougfoster.emailstanda...@gmail.com> wrote: > >> Murray, I was hoping your proposal to advance ARC was serious. >> > > If people think (and have evidence that) ARC is ready, then why would I > not be serious? > > The WG needs to resolve that "if" though. > A while back in the working group I asked people to provide data showing the efficacy of ARC. The response was crickets. What I see now is a bunch of hand waving but again, no data that can be evaluated. I am not against ARC but it needs to be evaluated on its own merits. It is a separate document and should not be conflated with DMARC. I'll also point out that WGLC is the inappropriate time to throw something new in the hopper, "just because". > > >> To Ale's concerns, I think a registration process would help mailing >> lists, but there are many options, and we do not need to define one single >> solution. Most of the mailbox providers already have a registration >> process for bulk senders, with a feedback loop for problem situations. I >> see plenty of opportunity for them to build on that. >> > > This also needs to be described if we think that's a part of the solution. > Again, WGLC is not the appropriate time to start throwing out new and undocumented proposals. > > My overall point is that this thread makes it seem like we're not putting > forward a complete solution. It feels a lot more like a proposed standard > that for its clear success depends on a bunch of other things that range > from experimental to abstract to undefined. And if that's a correct > summary, I'm asking if that's what we really want to do. It seems a little > haphazard, like we're scrambling to tie together the loose ends of a movie > plot. We need to do a good job of bringing our audience to as solid a > conclusion as possible, or the critics' reviews might not come out well. > My response to your statement "... this thread makes it seem like we're not putting forward a complete solution." is a complete solution to what? It seems like people are trying to throw in everything but the kitchen sink, including new proposals and rehashing old issues that were supposedly settled, as we go through last call. Michael Hammer ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Overall last-call comments on DMARC
On Thu, Apr 4, 2024 at 10:21 AM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > Murray, I was hoping your proposal to advance ARC was serious. > If people think (and have evidence that) ARC is ready, then why would I not be serious? The WG needs to resolve that "if" though. > To Ale's concerns, I think a registration process would help mailing > lists, but there are many options, and we do not need to define one single > solution. Most of the mailbox providers already have a registration > process for bulk senders, with a feedback loop for problem situations. I > see plenty of opportunity for them to build on that. > This also needs to be described if we think that's a part of the solution. My overall point is that this thread makes it seem like we're not putting forward a complete solution. It feels a lot more like a proposed standard that for its clear success depends on a bunch of other things that range from experimental to abstract to undefined. And if that's a correct summary, I'm asking if that's what we really want to do. It seems a little haphazard, like we're scrambling to tie together the loose ends of a movie plot. We need to do a good job of bringing our audience to as solid a conclusion as possible, or the critics' reviews might not come out well. -MSK, participant ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Overall last-call comments on DMARC
On Thu 04/Apr/2024 18:13:37 +0200 Murray S. Kucherawy wrote: On Thu, Apr 4, 2024 at 8:50 AM Alessandro Vesely wrote: I know what "contract" means abstractly, but what does this actually look like to someone that's looking for specific guidance? The text you have here, by itself, is vague and I don't think many operators will know what to do with it. A file in each user's home directory listing allowed pairs of ARC's d= domain and the list-id identifier of a List-Id: field? > I'm a Gmail user. What's a "home directory"? The place where they store your account information, including messages. Meanwhile, we can mention ARC, in Section 5.8 (minimal text proposed in another thread[*]). How much can we expand that? For example, can we whisper something about the need to trust specific sealers for specific streams? If you really need ARC to make all of this work and interoperate with lists, then I think we need to start talking about how we want to move ARC out of "Experimental" first so it can become a normative reference. Back to timing here. DMARCbis I-Ds seem to be mature enough to go out, even if there are not yet a practical solutions to the ML problem. Further delaying them until we find one is inadvisable. > Then why are we tossing about all these ideas during WGLC, muddying the waters? Muddying is unintentional. It is an attempt at marking the way forward. Yes, we need ARC, but we also need a method to convey agreements based on it. We couldn't spell out a solution even if ARC were standard track already. >> We can just hint at it. Parts of the Doug's text sound good for that. Here's a variation on it, mixed with the 2nd paragraph of Section 5.8: >> [...] So if I can summarize, I believe you're saying: Here's a Proposed Standard. In some common deployment scenarios, we know that it has some undesirable side effects. There isn't any concrete way to fix that as part of the PS. You could do some X, which is this new-ish experimental thing, or you could do some Y, or maybe both, and Z might help, "whatever", but only one of those is well-defined, and none of them are part of this PS nor are they published yet, and there's a non-zero chance that we'll run out of energy and not actually do so. Is that what you want to send to the IESG? The current text only mentions Y and Z, in about the same tone (other knowledge and analysis). Mentioning a work-in-progress X marks the way forward. If the WG agrees ARC is the way forward, that is. Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Overall last-call comments on DMARC
Murray, I was hoping your proposal to advance ARC was serious. Google has solved the problem of limited ARC deployment. To my mind, this means that we cannot revoke the experiment and we cannot do much to change it, so we might as well advance it to standards track. It became a de-facto standard on February 1. When an evaluator wants to accept Special Sender traffic, he needs two pieces of information: 1. How to detect that the message might qualify as a Special Sender 2. How to authenticate the Special Sender to differentiate that source from malicious actors. As my proposed text should have indicated, the evaluator has a huge obstacle when the Special Sender's Mail From address has been lost due to secondary forwarding. ARC fixes that problem rather well, while facilitating the entire process. To Ale's concerns, I think a registration process would help mailing lists, but there are many options, and we do not need to define one single solution. Most of the mailbox providers already have a registration process for bulk senders, with a feedback loop for problem situations. I see plenty of opportunity for them to build on that. On the other hand, I don't see our current document having much impact toward better message disposition; it simply does not break enough new ground. So I see no need to rush to completion. However, I can envision how the benefit from having ARC integrated into our text. I don't think we have satisfied our charter without it. I see every reason to proceed with ARC first. Doug Foster On Thu, Apr 4, 2024 at 12:14 PM Murray S. Kucherawy wrote: > On Thu, Apr 4, 2024 at 8:50 AM Alessandro Vesely wrote: > >> > I know what "contract" means abstractly, but what does this actually >> look >> > like to someone that's looking for specific guidance? The text you >> have >> > here, by itself, is vague and I don't think many operators will know >> what >> > to do with it. >> >> A file in each user's home directory listing allowed pairs of ARC's d= >> domain >> and the list-id identifier of a List-Id: field? > > > I'm a Gmail user. What's a "home directory"? > > >> Whatever. What do Google use >> to determine if an ARC seal is trusted? >> >> We don't have much concrete experience on how to set up a contract, >> though. >> > > This is what I'm worried about. We're in WGLC for the base document, so > this discussion is in that context. But is WGLC really a good time and > place to be introducing abstract ideas about how this might or might not > work? Aren't we looking to create something fairly complete and concrete > in a Proposed Standard? > > >> Meanwhile, we can mention ARC, in Section 5.8 (minimal text proposed >> in >> >> another thread[*]). How much can we expand that? For example, can we >> >> whisper something about the need to trust specific sealers for >> specific >> >> streams? >> > >> > If you really need ARC to make all of this work and interoperate with >> > lists, then I think we need to start talking about how we want to move >> ARC >> > out of "Experimental" first so it can become a normative reference. >> >> Back to timing here. DMARCbis I-Ds seem to be mature enough to go out, >> even if >> there are not yet a practical solutions to the ML problem. Further >> delaying >> them until we find one is inadvisable. >> > > Then why are we tossing about all these ideas during WGLC, muddying the > waters? > > >> Yes, we need ARC, but we also need a method to convey agreements based on >> it. >> We couldn't spell out a solution even if ARC were standard track already. >> > >> We can just hint at it. Parts of the Doug's text sound good for that. >> Here's >> a variation on it, mixed with the 2nd paragraph of Section 5.8: >> >> [...] >> > > So if I can summarize, I believe you're saying: > > Here's a Proposed Standard. In some common deployment scenarios, we know > that it has some undesirable side effects. There isn't any concrete way to > fix that as part of the PS. You could do some X, which is this new-ish > experimental thing, or you could do some Y, or maybe both, and Z might > help, "whatever", but only one of those is well-defined, and none of them > are part of this PS nor are they published yet, and there's a non-zero > chance that we'll run out of energy and not actually do so. > > Is that what you want to send to the IESG? > > -MSK > ___ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Overall last-call comments on DMARC
On Thu, Apr 4, 2024 at 8:50 AM Alessandro Vesely wrote: > > I know what "contract" means abstractly, but what does this actually > look > > like to someone that's looking for specific guidance? The text you have > > here, by itself, is vague and I don't think many operators will know > what > > to do with it. > > A file in each user's home directory listing allowed pairs of ARC's d= > domain > and the list-id identifier of a List-Id: field? I'm a Gmail user. What's a "home directory"? > Whatever. What do Google use > to determine if an ARC seal is trusted? > > We don't have much concrete experience on how to set up a contract, though. > This is what I'm worried about. We're in WGLC for the base document, so this discussion is in that context. But is WGLC really a good time and place to be introducing abstract ideas about how this might or might not work? Aren't we looking to create something fairly complete and concrete in a Proposed Standard? >> Meanwhile, we can mention ARC, in Section 5.8 (minimal text proposed in > >> another thread[*]). How much can we expand that? For example, can we > >> whisper something about the need to trust specific sealers for specific > >> streams? > > > > If you really need ARC to make all of this work and interoperate with > > lists, then I think we need to start talking about how we want to move > ARC > > out of "Experimental" first so it can become a normative reference. > > Back to timing here. DMARCbis I-Ds seem to be mature enough to go out, > even if > there are not yet a practical solutions to the ML problem. Further > delaying > them until we find one is inadvisable. > Then why are we tossing about all these ideas during WGLC, muddying the waters? > Yes, we need ARC, but we also need a method to convey agreements based on > it. > We couldn't spell out a solution even if ARC were standard track already. > > We can just hint at it. Parts of the Doug's text sound good for that. > Here's > a variation on it, mixed with the 2nd paragraph of Section 5.8: > > [...] > So if I can summarize, I believe you're saying: Here's a Proposed Standard. In some common deployment scenarios, we know that it has some undesirable side effects. There isn't any concrete way to fix that as part of the PS. You could do some X, which is this new-ish experimental thing, or you could do some Y, or maybe both, and Z might help, "whatever", but only one of those is well-defined, and none of them are part of this PS nor are they published yet, and there's a non-zero chance that we'll run out of energy and not actually do so. Is that what you want to send to the IESG? -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Overall last-call comments on DMARC
On Wed 03/Apr/2024 18:49:50 +0200 Murray S. Kucherawy wrote: On Wed, Apr 3, 2024 at 4:16 AM Alessandro Vesely wrote: Some sort of contract or agreement between sender and receiver seems to me to be unavoidable if we want to leverage ARC without having a global domain reputation system. We don't have a precise method to do that. We need to experiment and standardize something to that extent, which I hope this WG can do after publishing -bis. I know what "contract" means abstractly, but what does this actually look like to someone that's looking for specific guidance? The text you have here, by itself, is vague and I don't think many operators will know what to do with it. A file in each user's home directory listing allowed pairs of ARC's d= domain and the list-id identifier of a List-Id: field? Whatever. What do Google use to determine if an ARC seal is trusted? We don't have much concrete experience on how to set up a contract, though. Meanwhile, we can mention ARC, in Section 5.8 (minimal text proposed in another thread[*]). How much can we expand that? For example, can we whisper something about the need to trust specific sealers for specific streams? If you really need ARC to make all of this work and interoperate with lists, then I think we need to start talking about how we want to move ARC out of "Experimental" first so it can become a normative reference. Back to timing here. DMARCbis I-Ds seem to be mature enough to go out, even if there are not yet a practical solutions to the ML problem. Further delaying them until we find one is inadvisable. Yes, we need ARC, but we also need a method to convey agreements based on it. We couldn't spell out a solution even if ARC were standard track already. We can just hint at it. Parts of the Doug's text sound good for that. Here's a variation on it, mixed with the 2nd paragraph of Section 5.8: Mail Receivers MAY choose to accept email that fails the DMARC mechanism check even if the published Domain Owner Assessment Policy is "reject". Some legitimate messages are forwarded on behalf of an individual account, based on an established relationship between the sender and the account owner, but without domain owner involvement, These messages are legitimate in the sense that the RFC5322.From address represents the true author, but the messages do not produce DMARC "pass" on the last hop because the DKIM signature was broken (mailing list) or because authentication at the previous hop was based solely on SPF (non-mutant forwarding). In either case, such messages can be characterized as belonging to a very specific mail stream. An emerging protocol to help handling these cases is [ARC]. Besides providing an assertion of responsibility equivalent to DKIM, it also demonstrates the 'chain-of-custody' of a message by certifying what the Authentication-Results were when the message entered the forwarding organization(s). How to establish the recognition of the relationship between a given mail streams and the domain responsible for feeding it is outside the scope of this document. However, because of the considerations discussed in [RFC7960] and in Section 8.6 of this document, it is important that Mail Receivers not reject messages solely because of a published policy of "reject", but that they apply other knowledge to avoid situations such as rejection of legitimate messages. Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
