Re: [dmarc-ietf] Overall last-call comments on DMARC
> On Apr 1, 2024, at 2:43 PM, John R. Levine wrote: > > On Sun, 31 Mar 2024, Jim Fenton wrote: >> Based on the above problems, I do not think DMARC-bis should be published as >> a standards track document by IETF. > > This reminds me of the NAT wars in the 1990s. We all understand that DMARC > has a lot of problems, but it's far more widely used than many of the IETF's > published standards. It just makes us look insular and out of touch to > pretend that it doesn't exist, or if we shut our eyes it will go away. I’d be hugely dissapointed if this does not go into the standards track. N ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
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] 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
Re: [dmarc-ietf] Overall last-call comments on DMARC
On Wed, Apr 3, 2024 at 4:16 AM Alessandro Vesely wrote: > > So what are you suggesting should go in this document that's in WGLC? > > Section 8.6 states the ML problem very well, but it says nothing about the > way forward. Here, we agree. And I'm saying: If we have anything concrete we can say about the way forward, we really really should include it. My personal impression is that we do think we need something here, but there's no consensus yet on what (possibly due to lack of visible evidence), and it feels like a hole. > 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. > 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. -MSK, p11g ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Overall last-call comments on DMARC
In response to Ale's comment that we describe the mailing list problem without defining a path forward, I suggest the text below. Doug Foster Some legitimate messages are sent 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 because the sender does not have a DKIM private key from the domain owner. Mailing list messages are one example. We shall call these Special Senders. The mechanism which evaluators use to determine whether a message source should be classified as a Special Sender is outside the scope of this document. [ARC could be part of the process.] Once identified, an alternate authentication technique is needed to distinguish Special Senders from other sources, particularly malicious actors. To facilitate this alternate authentication, senders of such messages SHOULD use their own domain name for the Mail From address, and SHOULD apply a DKIM signature corresponding to the Mail From domain, and SHOULD ensure that the messages produce SPF Pass. When these identification measures are in place, the evaluator can authenticate the Special Sender, and use that identification to override DMARC Fail or DMARC No Policy. - For messages received directly, the evaluator detects the Special Sender's Mail From address or domain, and authenticates the message based on SPF Pass, aligned DKIM Pass, or both. Other message headers may also be used, specific to the situation, to ensure precise identification. - For messages received after secondary forwarding, but without Mail From rewrite, identification is based on the Mail From address and a verified DKIM signature aligned with the Mail From address. - For messages received after secondary forwarding and Mail From rewrite, authentication is more difficult. Before any message can be assigned Special Sender status, the evaluator must be able to detect that Special Sender status might apply. A DKIM signature for the Special Sender is the only verifiable identifier for this purpose. In most cases, the evaluator will need to use other message headers to supplement the DKIM signature as part of the Special Sender authentication, to ensure precise identification of the Special Sender messages. Alternatively, the evaluator may have reason to trust the secondary forwarder's authentication process, and accept the message on the basis of having been allowed through the secondary forwarder. On Wed, Apr 3, 2024 at 7:17 AM Alessandro Vesely wrote: > On 02/04/2024 20:16, Murray S. Kucherawy wrote: > > On Tue, Apr 2, 2024 at 9:01 AM Alessandro Vesely wrote: > > > >> By now, most mailing lists arranged to either rewrite From: or not > break > >> DKIM signatures. We all hope those hacks are temporary. > > > > What do you mean by "temporary", given the time scales that have > already > > passed since RFC 7489 saw wide deployment? Do you envision those > > techniques ending sometime soon? > > Yeah, the time scale is killing us. Is ten years soon enough? > >>> > >>> You tell me. You say you're hoping they're temporary, yet they've > been > >>> around a long time and I'm not sure that there's an alternative on the > >>> table. I'm asking you to explain. > >> > >> I believe alternatives are possible. Can't say how long it's going > >> to take, but I presume when they are available, the nasty hacks > >> will slowly fade out.> > > So what are you suggesting should go in this document that's in WGLC? > > > Section 8.6 states the ML problem very well, but it says nothing about the > way forward. Section 5.8, cross referenced with 8.6, talks about "other > knowledge and analysis". Neither that is forward looking, as it seems to > suggest some kind of presently available, heuristic content analysis. > > 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. > > 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? > > In Section 8.3 the draft says: > > 550 5.7.1 Email rejected per DMARC policy for example.com > > I guess it would be too much to say: > > 550-5.7.1 Email rejected per DMARC policy for example.com, > 550-5.7.1 ARC seal by forwarder.example verified but not trusted. > 550 5.7.1 See https://receiver.example/arc-streams-registration/ > > Wouldn't it? > > > Best > Ale > -- > > [*] >
Re: [dmarc-ietf] Overall last-call comments on DMARC
On 02/04/2024 20:16, Murray S. Kucherawy wrote: On Tue, Apr 2, 2024 at 9:01 AM Alessandro Vesely wrote: By now, most mailing lists arranged to either rewrite From: or not break DKIM signatures. We all hope those hacks are temporary. What do you mean by "temporary", given the time scales that have already passed since RFC 7489 saw wide deployment? Do you envision those techniques ending sometime soon? Yeah, the time scale is killing us. Is ten years soon enough? You tell me. You say you're hoping they're temporary, yet they've been around a long time and I'm not sure that there's an alternative on the table. I'm asking you to explain. I believe alternatives are possible. Can't say how long it's going to take, but I presume when they are available, the nasty hacks will slowly fade out.> So what are you suggesting should go in this document that's in WGLC? Section 8.6 states the ML problem very well, but it says nothing about the way forward. Section 5.8, cross referenced with 8.6, talks about "other knowledge and analysis". Neither that is forward looking, as it seems to suggest some kind of presently available, heuristic content analysis. 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. 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? In Section 8.3 the draft says: 550 5.7.1 Email rejected per DMARC policy for example.com I guess it would be too much to say: 550-5.7.1 Email rejected per DMARC policy for example.com, 550-5.7.1 ARC seal by forwarder.example verified but not trusted. 550 5.7.1 See https://receiver.example/arc-streams-registration/ Wouldn't it? Best Ale -- [*] https://mailarchive.ietf.org/arch/msg/dmarc/1aPplXPF1cYpnRzYHgxsTCPPzHg ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Overall last-call comments on DMARC
On Tue, Apr 2, 2024 at 9:01 AM Alessandro Vesely wrote: > By now, most mailing lists arranged to either rewrite From: or not > break > DKIM signatures. We all hope those hacks are temporary. > >>> > >>> What do you mean by "temporary", given the time scales that have > already > >>> passed since RFC 7489 saw wide deployment? Do you envision those > >>> techniques ending sometime soon? > >> > >> Yeah, the time scale is killing us. Is ten years soon enough? > > > > You tell me. You say you're hoping they're temporary, yet they've been > > around a long time and I'm not sure that there's an alternative on the > > table. I'm asking you to explain. > > I believe alternatives are possible. Can't say how long it's going to > take, > but I presume when they are available, the nasty hacks will slowly fade > out. > So what are you suggesting should go in this document that's in WGLC? > >>> If "most" mailing lists have arranged rewrites or non-mutation, and > this > >>> appears to be working, are there specific techniques we should > >>> standardize here? > >> > >> I believe it's possible to leverage ARC so as to overcome those mailing > >> lists hacks, for an expanding set of domains. It is not difficult to > >> modify ML software in order to rewrite and/or mutate on a per-user > basis. > >> One can obtain the same effect with existing software if it provides > for > >> twin lists or similar means to split users into two categories. > > > > This isn't consistent with your previous comment, which claimed that > "most" > > lists are already doing this. Your language here is more like a > proposal. > > I'm having a hard time following. > > Oh, perhaps you asked if we should standardize the nasty hack? IMHO, we > shouldn't. We didn't standardize COI either. > Same question. I can't tell if you're just pontificating about a variety of topics, or making concrete suggestions about what the -bis document really needs to say before this WG ships it. If the former, I suggest this be minimized as they're likely only distractions; if the latter, I'd love to see some proposed text. We should standardize some proposals that make ARC work consistently for > forwarders (including MLs) of any size and kind. > Do you have one to suggest? > > What is it that you believe we should be telling industry to do? > > Experiment with new proposals until we find one that works? > Same question. > >>> Are you suggesting we need some standard way to calculate and/or share > a > >>> sealer's reputation for any of this to work? > >> > >> Sealer's reputation is the same as domain reputation. Good to have it, > >> whenever it comes. > > > > I interpreted your earlier remark to be a claim that this stuff won't > work > > absent such data. > > A reliable reputation database will certainly make everything email work > better. However, ARC usage with local trust contracts, granted on a case > by > case basis could work even without it, methinks. > Do you have specific text to suggest? > >> For ARC, I'd rather consider per-forwarder contracts. Forwarding (of > >> which MLs are a case) doesn't happen out of the blue. It has to be set > >> up. Involving the target receiver in the setup may make it trust the > >> sender's seals, when they belong to the stream thus set up and > >> identified. > > > > So, a "contract" between each mailing list and each subscriber? What > would > > that mean? > > A contract would mean the same as COI, but involving (also) the > subscriber's > MBP. Is it really you? You sure you want to subscribe to this? Then > I'll > trust the ML when it ARC-seals messages with this List-Id: destined to > you, for > example. > Have you tried this technique? Has anyone? Does it work? -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 Tue 02/Apr/2024 15:35:05 +0200 Murray S. Kucherawy wrote: On Tue, Apr 2, 2024 at 3:01 AM Alessandro Vesely wrote: By now, most mailing lists arranged to either rewrite From: or not break DKIM signatures. We all hope those hacks are temporary. What do you mean by "temporary", given the time scales that have already passed since RFC 7489 saw wide deployment? Do you envision those techniques ending sometime soon? Yeah, the time scale is killing us. Is ten years soon enough? You tell me. You say you're hoping they're temporary, yet they've been around a long time and I'm not sure that there's an alternative on the table. I'm asking you to explain. I believe alternatives are possible. Can't say how long it's going to take, but I presume when they are available, the nasty hacks will slowly fade out. If "most" mailing lists have arranged rewrites or non-mutation, and this appears to be working, are there specific techniques we should standardize here? I believe it's possible to leverage ARC so as to overcome those mailing lists hacks, for an expanding set of domains. It is not difficult to modify ML software in order to rewrite and/or mutate on a per-user basis. One can obtain the same effect with existing software if it provides for twin lists or similar means to split users into two categories. > This isn't consistent with your previous comment, which claimed that "most" lists are already doing this. Your language here is more like a proposal. I'm having a hard time following. Oh, perhaps you asked if we should standardize the nasty hack? IMHO, we shouldn't. We didn't standardize COI either. We should standardize some proposals that make ARC work consistently for forwarders (including MLs) of any size and kind. What is it that you believe we should be telling industry to do? Experiment with new proposals until we find one that works? Are you suggesting we need some standard way to calculate and/or share a sealer's reputation for any of this to work? Sealer's reputation is the same as domain reputation. Good to have it, whenever it comes. I interpreted your earlier remark to be a claim that this stuff won't work absent such data. A reliable reputation database will certainly make everything email work better. However, ARC usage with local trust contracts, granted on a case by case basis could work even without it, methinks. For ARC, I'd rather consider per-forwarder contracts. Forwarding (of which MLs are a case) doesn't happen out of the blue. It has to be set up. Involving the target receiver in the setup may make it trust the sender's seals, when they belong to the stream thus set up and identified. So, a "contract" between each mailing list and each subscriber? What would that mean? A contract would mean the same as COI, but involving (also) the subscriber's MBP. Is it really you? You sure you want to subscribe to this? Then I'll trust the ML when it ARC-seals messages with this List-Id: destined to you, for example. Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Overall last-call comments on DMARC
On Tue, Apr 2, 2024 at 3:01 AM Alessandro Vesely wrote: > >> By now, most mailing lists arranged to either rewrite From: or not > break > >> DKIM signatures. We all hope those hacks are temporary. > > > > > What do you mean by "temporary", given the time scales that have already > > passed since RFC 7489 saw wide deployment? Do you envision those > > techniques ending sometime soon? > > Yeah, the time scale is killing us. Is ten years soon enough? > You tell me. You say you're hoping they're temporary, yet they've been around a long time and I'm not sure that there's an alternative on the table. I'm asking you to explain. > > If "most" mailing lists have arranged rewrites or non-mutation, and this > > appears to be working, are there specific techniques we should > standardize > > here? > > I believe it's possible to leverage ARC so as to overcome those mailing > lists > hacks, for an expanding set of domains. It is not difficult to modify ML > software in order to rewrite and/or mutate on a per-user basis. One can > obtain > the same effect with existing software if it provides for twin lists or > similar > means to split users into two categories. > This isn't consistent with your previous comment, which claimed that "most" lists are already doing this. Your language here is more like a proposal. I'm having a hard time following. What is it that you believe we should be telling industry to do? > Are you suggesting we need some standard way to calculate and/or share a > > sealer's reputation for any of this to work? > > Sealer's reputation is the same as domain reputation. Good to have it, > whenever it comes. > I interpreted your earlier remark to be a claim that this stuff won't work absent such data. > For ARC, I'd rather consider per-forwarder contracts. Forwarding (of > which MLs > are a case) doesn't happen out of the blue. It has to be set up. > Involving > the target receiver in the setup may make it trust the sender's seals, > when > they belong to the stream thus set up and identified. > So, a "contract" between each mailing list and each subscriber? What would that mean? -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 Mon 01/Apr/2024 16:35:28 +0200 Murray S. Kucherawy wrote: On Mon, Apr 1, 2024 at 4:44 AM Alessandro Vesely wrote: * Mailing lists — Mailing list operators, including ietf.org, have had to implement rewriting of From addresses such as u...@example.com becomes user=40example@dmarc.ietf.org when a p=strict or p=quarantine policy is in place. This works to some extent for IETF, but there is an enormous number of mailing list operators, each of whom would need to implement address rewriting. While address rewriting is not the recommended solution, it is widely used because of the widespread inappropriate use described above. >> By now, most mailing lists arranged to either rewrite From: or not break DKIM signatures. We all hope those hacks are temporary. > What do you mean by "temporary", given the time scales that have already passed since RFC 7489 saw wide deployment? Do you envision those techniques ending sometime soon? Yeah, the time scale is killing us. Is ten years soon enough? If "most" mailing lists have arranged rewrites or non-mutation, and this appears to be working, are there specific techniques we should standardize here? I believe it's possible to leverage ARC so as to overcome those mailing lists hacks, for an expanding set of domains. It is not difficult to modify ML software in order to rewrite and/or mutate on a per-user basis. One can obtain the same effect with existing software if it provides for twin lists or similar means to split users into two categories. ARC provides a protocol whereby a mailing list can certify its behavior to an end receiver. Unfortunately, we are still missing a protocol whereby trusting an ARC sealer can be established by a receiver for each mail stream. We are halfway across the ford. > Are you suggesting we need some standard way to calculate and/or share a sealer's reputation for any of this to work? Sealer's reputation is the same as domain reputation. Good to have it, whenever it comes. For ARC, I'd rather consider per-forwarder contracts. Forwarding (of which MLs are a case) doesn't happen out of the blue. It has to be set up. Involving the target receiver in the setup may make it trust the sender's seals, when they belong to the stream thus set up and identified. Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Overall last-call comments on DMARC
On Sun, 31 Mar 2024, Jim Fenton wrote: Based on the above problems, I do not think DMARC-bis should be published as a standards track document by IETF. This reminds me of the NAT wars in the 1990s. We all understand that DMARC has a lot of problems, but it's far more widely used than many of the IETF's published standards. It just makes us look insular and out of touch to pretend that it doesn't exist, or if we shut our eyes it will go away. 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
On Mon, Apr 1, 2024 at 4:44 AM Alessandro Vesely wrote: > > * Mailing lists — Mailing list operators, including ietf.org, have had > to > > implement rewriting of From addresses such as u...@example.com becomes > > user=40example@dmarc.ietf.org when a p=strict or p=quarantine > policy is in > > place. This works to some extent for IETF, but there is an enormous > number of > > mailing list operators, each of whom would need to implement address > rewriting. > > While address rewriting is not the recommended solution, it is widely > used > > because of the widespread inappropriate use described above. > > By now, most mailing lists arranged to either rewrite From: or not break > DKIM > signatures. We all hope those hacks are temporary. > What do you mean by "temporary", given the time scales that have already passed since RFC 7489 saw wide deployment? Do you envision those techniques ending sometime soon? If "most" mailing lists have arranged rewrites or non-mutation, and this appears to be working, are there specific techniques we should standardize here? > ARC provides a protocol > whereby a mailing list can certify its behavior to an end receiver. > Unfortunately, we are still missing a protocol whereby trusting an ARC > sealer > can be established by a receiver for each mail stream. We are halfway > across > the ford. > Are you suggesting we need some standard way to calculate and/or share a sealer's reputation for any of this to work? -MSK, p11g ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Overall last-call comments on DMARC
Let me add a few comments that seem obvious to me. On Mon 01/Apr/2024 04:00:03 +0200 Jim Fenton wrote: In addition to the editorial review I have provided, I have significant concerns regarding the standardization of DMARC-bis. I do not expect that the working group rough consensus will necessarily agree with these concerns, but I want to state them for the working group and will probably restate them for a different audience at IETF last call. I like to use the health care industry “safe and effective” analogy here. ## Safety Deployment of the first iteration of DMARC has resulted in significant deployment problems, interfering with the delivery of some email from domains with a p=strict or p=quarantine policy. Examples are: * Inappropriate use of p=reject and p=quarantine — Many domains publish restrictive policies in an effort to suppress misuse of their domain names, without regard for usage patterns. A number of online tools warn users and domain administrators that their domains aren’t fully protected if they don’t have a restricted policy, without regard to how the domain is used. Blanket policies, like DHS [BOD 18-01](https://www.cisa.gov/news-events/directives/bod-18-01-enhance-email-and-web-security), require restrictive policies for a wide range of domains (in this case for all US Government agencies). It is unlikely that the publication of DMARC-bis will rectify either of these things. This topic is treated very well in Section 8.6, Interoperability Considerations. * Mailing lists — Mailing list operators, including ietf.org, have had to implement rewriting of From addresses such as u...@example.com becomes user=40example@dmarc.ietf.org when a p=strict or p=quarantine policy is in place. This works to some extent for IETF, but there is an enormous number of mailing list operators, each of whom would need to implement address rewriting. While address rewriting is not the recommended solution, it is widely used because of the widespread inappropriate use described above. By now, most mailing lists arranged to either rewrite From: or not break DKIM signatures. We all hope those hacks are temporary. ARC provides a protocol whereby a mailing list can certify its behavior to an end receiver. Unfortunately, we are still missing a protocol whereby trusting an ARC sealer can be established by a receiver for each mail stream. We are halfway across the ford. * Receive-side forwarders — Many receive-side forwarders (e.g. alumni and organizational domains providing affinity email addresses) preserve the integrity of DKIM signatures, but not all do. This is similar to the mailing list problem, except that it is more likely to occur even with domains used only for transactional email, which is otherwise one of the more promising use cases for DMARC. Same as above, although most forwarders don't break DKIM signatures. Whether to rewrite the bounce address is still debatable. ## Effectiveness There are also factors that call into question whether DMARC(-bis) does what it purports to do (protecting the domain name), or whether that is valuable: * Visibility of domain names — One of the justifications given for DMARC deployment is to protect the sender’s domain name: to prevent attackers from spoofing the From address of addresses in that domain. But many mail user agents (an increasing number, it seems) do not display the sender’s email address, only the friendly name. In some cases, the recipient can request to see the message header or source, but this requires specific effort and would normally only be done when the user considers a message to be suspicious. I regularly receive messages claiming to be from a bank, a well-known brand ,or even from myself, but with a completely unrelated email address. These messages pass DMARC (because the domain in the From address is controlled by them or has no DMARC record) but are still effective as potential phishing messages. These are considered out of scope for DMARC. Yes. In addition, it seems that even if a MUA were able to prominently display that a message is scam, average users would not notice it. Presumably, we need domain reputation to address that. * Normalization of rewriting — The rewriting of From addresses described above might serve to accustom users to From address rewriting. Messages with email addresses that look like they have been rewritten can easily be used by attackers to bypass DMARC policies and reporting. Yes. ## General In 2013, a similar protocol, ADSP [RFC5617], was [changed](https://datatracker.ietf.org/doc/status-change-adsp-rfc5617-to-historic/) from standards track to historic, citing limited use and harm caused by incorrect configuration very similar to the inappropriate use of p=reject described above. While DMARC has had considerably more use than ADSP, the harm that has been caused is correspondingly higher. Most ADSP issues were
[dmarc-ietf] Overall last-call comments on DMARC
In addition to the editorial review I have provided, I have significant concerns regarding the standardization of DMARC-bis. I do not expect that the working group rough consensus will necessarily agree with these concerns, but I want to state them for the working group and will probably restate them for a different audience at IETF last call. I like to use the health care industry “safe and effective” analogy here. ## Safety Deployment of the first iteration of DMARC has resulted in significant deployment problems, interfering with the delivery of some email from domains with a p=strict or p=quarantine policy. Examples are: * Inappropriate use of p=reject and p=quarantine — Many domains publish restrictive policies in an effort to suppress misuse of their domain names, without regard for usage patterns. A number of online tools warn users and domain administrators that their domains aren’t fully protected if they don’t have a restricted policy, without regard to how the domain is used. Blanket policies, like DHS [BOD 18-01](https://www.cisa.gov/news-events/directives/bod-18-01-enhance-email-and-web-security), require restrictive policies for a wide range of domains (in this case for all US Government agencies). It is unlikely that the publication of DMARC-bis will rectify either of these things. * Mailing lists — Mailing list operators, including ietf.org, have had to implement rewriting of From addresses such as u...@example.com becomes user=40example@dmarc.ietf.org when a p=strict or p=quarantine policy is in place. This works to some extent for IETF, but there is an enormous number of mailing list operators, each of whom would need to implement address rewriting. While address rewriting is not the recommended solution, it is widely used because of the widespread inappropriate use described above. * Receive-side forwarders — Many receive-side forwarders (e.g. alumni and organizational domains providing affinity email addresses) preserve the integrity of DKIM signatures, but not all do. This is similar to the mailing list problem, except that it is more likely to occur even with domains used only for transactional email, which is otherwise one of the more promising use cases for DMARC. ## Effectiveness There are also factors that call into question whether DMARC(-bis) does what it purports to do (protecting the domain name), or whether that is valuable: * Visibility of domain names — One of the justifications given for DMARC deployment is to protect the sender’s domain name: to prevent attackers from spoofing the From address of addresses in that domain. But many mail user agents (an increasing number, it seems) do not display the sender’s email address, only the friendly name. In some cases, the recipient can request to see the message header or source, but this requires specific effort and would normally only be done when the user considers a message to be suspicious. I regularly receive messages claiming to be from a bank, a well-known brand ,or even from myself, but with a completely unrelated email address. These messages pass DMARC (because the domain in the From address is controlled by them or has no DMARC record) but are still effective as potential phishing messages. These are considered out of scope for DMARC. * Normalization of rewriting — The rewriting of From addresses described above might serve to accustom users to From address rewriting. Messages with email addresses that look like they have been rewritten can easily be used by attackers to bypass DMARC policies and reporting. ## General In 2013, a similar protocol, ADSP [RFC5617], was [changed](https://datatracker.ietf.org/doc/status-change-adsp-rfc5617-to-historic/) from standards track to historic, citing limited use and harm caused by incorrect configuration very similar to the inappropriate use of p=reject described above. While DMARC has had considerably more use than ADSP, the harm that has been caused is correspondingly higher. Based on the above problems, I do not think DMARC-bis should be published as a standards track document by IETF. -Jim___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
