[dmarc-ietf] Messages from the dmarc list for the week ending Sun Aug 7 06:00:04 2022
Count| Bytes | Who ++--- 61 ( 100%) | 488594 ( 100%) | Total 14 (23.0%) | 84075 (17.2%) | Alessandro Vesely 13 (21.3%) | 70989 (14.5%) | John Levine 11 (18.0%) | 108102 (22.1%) | Douglas Foster 7 (11.5%) | 58068 (11.9%) | Murray S. Kucherawy 5 ( 8.2%) | 63202 (12.9%) | Scott Kitterman 4 ( 6.6%) | 22344 ( 4.6%) | Barry Leiba 3 ( 4.9%) | 46499 ( 9.5%) | Todd Herr 2 ( 3.3%) | 21739 ( 4.4%) | Ken O'Driscoll 1 ( 1.6%) | 7666 ( 1.6%) | tjw ietf 1 ( 1.6%) | 5910 ( 1.2%) | John R. Levine ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Collecting message metadata, was Time to work on failure reporting
On Sat 06/Aug/2022 16:29:47 +0200 John Levine wrote: I don't understand what you mean by "no data collection." It is true that you can send a failure report immediately without saving anything for later. “Those who cannot remember the past are condemned to repeat it.” – George Santayana, The Life of Reason, 1905. Perhaps I'm unusually dense today but I still don't understand what any of this has to do with DMARC failure reports. By remembering failure reports issued in the past, new failures having already reported characteristics (e.g. same forwarder) can be silently ignored. That would greatly reduce noise. Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Collecting message metadata, was Time to work on failure reporting
On Sun, Aug 7, 2022 at 6:04 AM Alessandro Vesely wrote: > On Sat 06/Aug/2022 16:29:47 +0200 John Levine wrote: > >>> I don't understand what you mean by "no data collection." It is true > that > >>> you can send a failure report immediately without saving anything for > >>> later. > >> > >> “Those who cannot remember the past are condemned to repeat it.” – > George > >> Santayana, The Life of Reason, 1905. > > > > Perhaps I'm unusually dense today but I still don't understand what any > of > > this has to do with DMARC failure reports. > > > By remembering failure reports issued in the past, new failures having > already reported characteristics (e.g. same forwarder) can be silently > ignored. That would greatly reduce noise. > > > Best > Ale > -- > This is a horrible idea. It presupposes that failures from the same origin (e.g. same forwarder) at different points in time are the result of the same underlying cause. This may be true in some cases but not true in other cases. Operational environments are not static. Even for short time frames this is a bad approach. Michael Hammer ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] no zone cuts, no Shortcuts
On August 6, 2022 11:10:28 AM UTC, Alessandro Vesely wrote: >On Fri 05/Aug/2022 17:58:48 +0200 Scott Kitterman wrote: >> I don't think it changes anything technically, but I think it goes >> some way to address Ale's concerns about clarity. > > >Some way it goes. In that case, does anyone have a problem with the change. I'm happy to support it as a step towards consensus on the wording. Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Collecting message metadata, was Time to work on failure reporting
By remembering failure reports issued in the past, new failures having already reported characteristics (e.g. same forwarder) can be silently ignored. That would greatly reduce noise. This is a horrible idea. It presupposes that failures from the same origin (e.g. same forwarder) at different points in time are the result of the same underlying cause. This may be true in some cases but not true in other cases. Operational environments are not static. Even for short time frames this is a bad approach. It also misses the fact that "already reported characteristics" is undefined. For example, the guy complaining about reports from NANOG messages considers all reports about a message forwarded through NANOG are the same, even though they could have come from a dozen different recipients that don't know about each other. We have plenty of work already without inventing more. Let's agree not to do this and get back to work on what we've already agreed to do. Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] no zone cuts, no Shortcuts
It appears that Scott Kitterman said: > > >On August 6, 2022 11:10:28 AM UTC, Alessandro Vesely wrote: >>On Fri 05/Aug/2022 17:58:48 +0200 Scott Kitterman wrote: >>> I don't think it changes anything technically, but I think it goes >>> some way to address Ale's concerns about clarity. >> >> >>Some way it goes. > >In that case, does anyone have a problem with the change. I'm happy to >support it as a step towards consensus on the >wording. I don't think it makes it worse. I'm thinking we might rewrite the intro to the tree walk by listing the situations where you need to do one rather than the ones where you don't, e.g.: - looking for policy domain for the From domain unless it says psd=n - if SPF policy says relaxed alignment and From and SPF are different, finding org domains - if DKIM policy says relaxed alignment and From and DKIM are different, finding org domains I would not list any shortcuts other than maybe that you can remember and reuse queries you've already made. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
[dmarc-ietf] no zone cuts, no Shortcuts
The most obvious shortcuts are that names must match on the right-most two labels before the org domain is found, and must match on the entire org domain once it is known. A high percentage of tree walks can be eliminated with these two tests. On Sun, Aug 7, 2022, 2:56 PM John Levine wrote: > It appears that Scott Kitterman said: > > > > > >On August 6, 2022 11:10:28 AM UTC, Alessandro Vesely > wrote: > >>On Fri 05/Aug/2022 17:58:48 +0200 Scott Kitterman wrote: > >>> I don't think it changes anything technically, but I think it goes > >>> some way to address Ale's concerns about clarity. > >> > >> > >>Some way it goes. > > > >In that case, does anyone have a problem with the change. I'm happy to > support it as a step towards consensus on the > >wording. > > I don't think it makes it worse. > > I'm thinking we might rewrite the intro to the tree walk by listing the > situations where > you need to do one rather than the ones where you don't, e.g.: > > - looking for policy domain for the From domain unless it says psd=n > > - if SPF policy says relaxed alignment and From and SPF are different, > finding org domains > > - if DKIM policy says relaxed alignment and From and DKIM are different, > finding org domains > > I would not list any shortcuts other than maybe that you can remember and > reuse > queries you've already made. > > R's, > John > > ___ > 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] no zone cuts, no Shortcuts
On Sunday, August 7, 2022 2:55:48 PM EDT John Levine wrote: > It appears that Scott Kitterman said: > >On August 6, 2022 11:10:28 AM UTC, Alessandro Vesely wrote: > >>On Fri 05/Aug/2022 17:58:48 +0200 Scott Kitterman wrote: > >>> I don't think it changes anything technically, but I think it goes > >>> > >>> some way to address Ale's concerns about clarity. > >> > >>Some way it goes. > > > >In that case, does anyone have a problem with the change. I'm happy to > >support it as a step towards consensus on the wording. > > I don't think it makes it worse. > > I'm thinking we might rewrite the intro to the tree walk by listing the > situations where you need to do one rather than the ones where you don't, > e.g.: > > - looking for policy domain for the From domain unless it says psd=n > > - if SPF policy says relaxed alignment and From and SPF are different, > finding org domains > > - if DKIM policy says relaxed alignment and From and DKIM are different, > finding org domains > > I would not list any shortcuts other than maybe that you can remember and > reuse queries you've already made. I think that could work. Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Girl Scout troops vs MLM problems (#70)
Moving this back to the main list: I said: Even if I agreed that it would be a good idea for every mailing list in the world to rewrite From lines so it's harder to tell who the messages are from and you can't reply reliably, there's no way that would survive last call. Remember that a few large mail providers abused DMARC to outsource the cost of leaking their user address books to crooks, and screwed up every mailing list in the world as a side effect. Blaming the victim is not the answer. Unfortunately, there is no good answer. Scott said: Agreed. On my phone I use an MUA which will display either the friendly name or the address, not both. I routinely get messages that I can't tell who they are from without reading the raw header if someone forgets to put their name at the end of the mail because I no longer get their address in the normal display thanks to rewriting. I think, as was discussed at the meeting, what types of domains DMARC is suitable for needs to have some kind of MUST or MUST NOT depending on how it's worded then with some non-normative words in an appendix which discuss options for damage containment when the MUST is ignored. On Sun, 7 Aug 2022, Alessandro Vesely wrote: Saying that domains with human users MUST NOT use DMARC is not a solution either. The wording has to express the explanation Pete gave at the meeting, which sounds very close to RFC 6919. Letting the victim die is not the solution either. Among the solutions that MLMs adopt, some allow to undo From: rewriting at the MDA level. ARC doesn't preclude From munging. ARC verifiers can restore the original From: at rMDA level too. Actually, small receivers can simply trust selected, DMARC-aligned mailing lists and restore the original From: in the cases where MLM saved it (w/o ARC). This kind of hack could be set up really quick. Please please can we stop doing this. Trying to unmunge rewritten From: headers is totally out of scope for this group, and even if it weren't it does not scale and has terrible security problems. (If good guys can put in real rewrites, bad guys can put in fake rewrites, and if a recipient can tell whose rewrites are good enough to unmunge, it can equally well ignore whatever problem the rewrite was supposed to fix.) I will try and write something similar to what Scott suggests, describing the problems without making us look foolish, and mentioning that there are workarounds if you insist on sending p=reject messages on paths that DMARC cannot describe. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Girl Scout troops vs MLM problems (#70)
Yes. Evaluators need to use much more sophistication, when applying DMARC, than simply applying the formula and doing whatever the policy suggests. Developers need to provide exception mechanisms which permit that complexity to be implemented as local policy. This means we need language to deprecate implementation designs that assume Fail=Malicious. DF On Sun, Aug 7, 2022, 6:41 PM John R Levine wrote: > Moving this back to the main list: > > I said: > Even if I agreed that it would be a good idea for every mailing list in the > world to rewrite From lines so it's harder to tell who the messages are > from and > you can't reply reliably, there's no way that would survive last call. > Remember that a few large mail providers abused DMARC to outsource the > cost of > leaking their user address books to crooks, and screwed up every mailing > list in > the world as a side effect. > Blaming the victim is not the answer. Unfortunately, there is no good > answer. > > Scott said: > Agreed. On my phone I use an MUA which will display either the friendly > name or > the address, not both. I routinely get messages that I can't tell who they > are > from without reading the raw header if someone forgets to put their name > at the > end of the mail because I no longer get their address in the normal display > thanks to rewriting. I think, as was discussed at the meeting, what types > of > domains DMARC is suitable for needs to have some kind of MUST or MUST NOT > depending on how it's worded then with some non-normative words in an > appendix > which discuss options for damage containment when the MUST is ignored. > > On Sun, 7 Aug 2022, Alessandro Vesely wrote: > > Saying that domains with human users MUST NOT use DMARC is not a solution > > either. The wording has to express the explanation Pete gave at the > > meeting, which sounds very close to RFC 6919. > > > > Letting the victim die is not the solution either. Among the solutions > > that MLMs adopt, some allow to undo From: rewriting at the MDA level. > ARC > > doesn't preclude From munging. ARC verifiers can restore the original > > From: at rMDA level too. Actually, small receivers can simply trust > > selected, DMARC-aligned mailing lists and restore the original From: in > the > > cases where MLM saved it (w/o ARC). This kind of hack could be set up > > really quick. > > Please please can we stop doing this. Trying to unmunge rewritten From: > headers is totally out of scope for this group, and even if it weren't it > does not scale and has terrible security problems. (If good guys can put > in real rewrites, bad guys can put in fake rewrites, and if a recipient > can tell whose rewrites are good enough to unmunge, it can equally well > ignore whatever problem the rewrite was supposed to fix.) > > I will try and write something similar to what Scott suggests, describing > the problems without making us look foolish, and mentioning that there are > workarounds if you insist on sending p=reject messages on paths that DMARC > cannot describe. > > R's, > John > > ___ > 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] Girl Scout troops vs MLM problems (#70)
On Sun, Aug 7, 2022 at 6:41 PM John R Levine wrote: > Moving this back to the main list: > > I said: > Even if I agreed that it would be a good idea for every mailing list in the > world to rewrite From lines so it's harder to tell who the messages are > from and > you can't reply reliably, there's no way that would survive last call. > Remember that a few large mail providers abused DMARC to outsource the > cost of > leaking their user address books to crooks, and screwed up every mailing > list in > the world as a side effect. > Blaming the victim is not the answer. Unfortunately, there is no good > answer. > > Scott said: > Agreed. On my phone I use an MUA which will display either the friendly > name or > the address, not both. I routinely get messages that I can't tell who they > are > from without reading the raw header if someone forgets to put their name > at the > end of the mail because I no longer get their address in the normal display > thanks to rewriting. I think, as was discussed at the meeting, what types > of > domains DMARC is suitable for needs to have some kind of MUST or MUST NOT > depending on how it's worded then with some non-normative words in an > appendix > which discuss options for damage containment when the MUST is ignored. > I'm surprised that John did not invoke King Canute at this comment. That ship has sailed. The horse bolted the barn and closing the barn door won't put the horse back in. Domain administrators will implement DMARC policy or not as they choose. > > On Sun, 7 Aug 2022, Alessandro Vesely wrote: > > Saying that domains with human users MUST NOT use DMARC is not a solution > > either. The wording has to express the explanation Pete gave at the > > meeting, which sounds very close to RFC 6919. > > > > Letting the victim die is not the solution either. Among the solutions > > that MLMs adopt, some allow to undo From: rewriting at the MDA level. > ARC > > doesn't preclude From munging. ARC verifiers can restore the original > > From: at rMDA level too. Actually, small receivers can simply trust > > selected, DMARC-aligned mailing lists and restore the original From: in > the > > cases where MLM saved it (w/o ARC). This kind of hack could be set up > > really quick. > > Please please can we stop doing this. Trying to unmunge rewritten From: > headers is totally out of scope for this group, and even if it weren't it > does not scale and has terrible security problems. (If good guys can put > in real rewrites, bad guys can put in fake rewrites, and if a recipient > can tell whose rewrites are good enough to unmunge, it can equally well > ignore whatever problem the rewrite was supposed to fix.) > +1 > > I will try and write something similar to what Scott suggests, describing > the problems without making us look foolish, and mentioning that there are > workarounds if you insist on sending p=reject messages on paths that DMARC > cannot describe. > I look forward to seeing this. > > R's, > John > > ___ > 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] Girl Scout troops vs MLM problems (#70)
On Sun, Aug 7, 2022 at 4:07 PM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > Evaluators need to use much more sophistication, when applying DMARC, than > simply applying the formula and doing whatever the policy suggests. > I think that's common practice. The people on this list who are still M3AAWG regulars can tell me if I'm wrong, but my impression is that it is common industry practice to factor the output of DMARC, just as DKIM and SPF, into to whatever local secret sauce an operator chooses to employ when making handling decisions. DMARC is rarely dispositive on its own. There are plenty of other practices that usually go into a final handling decision; RFC 6647 comes to mind as one example, RFC 5782 as another. Developers need to provide exception mechanisms which permit that > complexity to be implemented as local policy. This means we need language > to deprecate implementation designs that assume Fail=Malicious. > We can't require such mechanisms as they are outside of the scope of the protocol, but we could say it's common to do so. For that matter, Section 1 of RFC 6647 already says this: Absent a perfect abuse-detection mechanism that incurs no cost, the current requirement is for an array of techniques to be used by each filtering system. They range in cost, effectiveness, and types of abuse techniques they target. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
