Re: [dmarc-ietf] Collecting message metadata, was Time to work on failure reporting
Most receivers don’t provide failure reports but sometimes failure reports (when available) can be useful. I realize there are privacy and regulatory concerns. Would it be possible to reduce the scope of the failure report in general to address the privacy concerns so that they’re more widely implemented? The trade offs might be worth it to have a stripped down failure report if there was a way to do it so the failure report would be useful but not intrusive? The spec allows you to redact all you want, but history has shown that if you send anything at all, there is some risk of PII leaks. Mike noted that there are places that exchange failure reports by private agreement, presumably including protections for PII. I think that's the best one can realistically expect. 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] Collecting message metadata, was Time to work on failure reporting
On Wed, Aug 17, 2022 at 4:28 AM Alessandro Vesely wrote: > On Wed 17/Aug/2022 07:20:02 +0200 Neil Anuskiewicz wrote: > >> On Aug 9, 2022, at 3:17 AM, Ken O'Driscoll wrote: > >> > >>> Any hint about why it's not used? > >> > >> PII. Report generators are reluctant to send reports that may contain > PII for compliance, security, and privacy reasons > > > > Most receivers don’t provide failure reports but sometimes failure > reports (when available) can be useful. > > > What can they be useful for? Possible answers (my guessing): > > * A large, complicated organization can find out which machine/ job is > producing bad authentication. (Why cannot this be found in aggregate > reports?) > > When a domain's mail is failing to authenticate, aggregate reports are most useful at identifying the culprit if there is a one-to-one relationship between source IP and host generating mail messages. For the cases of a farm of two or more machines sending from behind a single IP address, the usefulness of the aggregate report in identifying the troublesome host(s) diminishes in direct correlation to the number of hosts using the IP. -- *Todd Herr * | Technical Director, Standards and Ecosystem *e:* todd.h...@valimail.com *m:* 703.220.4153 This email and all data transmitted with it contains confidential and/or proprietary information intended solely for the use of individual(s) authorized to receive it. If you are not an intended and authorized recipient you are hereby notified of any use, disclosure, copying or distribution of the information included in this transmission is prohibited and may be unlawful. Please immediately notify the sender by replying to this email and then delete it from your system. ___ 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 Wed 17/Aug/2022 07:20:02 +0200 Neil Anuskiewicz wrote: On Aug 9, 2022, at 3:17 AM, Ken O'Driscoll wrote: Any hint about why it's not used? PII. Report generators are reluctant to send reports that may contain PII for compliance, security, and privacy reasons Most receivers don’t provide failure reports but sometimes failure reports (when available) can be useful. What can they be useful for? Possible answers (my guessing): * A large, complicated organization can find out which machine/ job is producing bad authentication. (Why cannot this be found in aggregate reports?) * A developer can find out which details of a signature didn't match. (This requires full details, though.) I realize there are privacy and regulatory concerns. Would it be possible to reduce the scope of the failure report in general to address the privacy concerns so that they’re more widely implemented? One way could be to only report messages that were purposely sent for debugging. The sender of a debug message would be supposed to not put sensitive data in it. The trade offs might be worth it to have a stripped down failure report if there was a way to do it so the failure report would be useful but not intrusive? The problem is to know what data is useful. Signature checking may need canonicalized header or body, which leaves almost no room for redaction. 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 Aug 9, 2022, at 3:17 AM, Ken O'Driscoll > wrote: > > >> >> >> Any hint about why it's not used? >> > > PII. Report generators are reluctant to send reports that may contain PII for > compliance, security, and privacy reasons Most receivers don’t provide failure reports but sometimes failure reports (when available) can be useful. I realize there are privacy and regulatory concerns. Would it be possible to reduce the scope of the failure report in general to address the privacy concerns so that they’re more widely implemented? The trade offs might be worth it to have a stripped down failure report if there was a way to do it so the failure report would be useful but not intrusive? ___ 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 Wed 10/Aug/2022 17:46:46 +0200 Barry Leiba wrote: I think that's enough that we should leave it in. I also see a fair number of reports in wrong format, a consistent wrong format starting with "A message claiming to be from you has failed the published DMARC policy for your domain." from at least two reporters which tells me that there is a DMARC implementation that got the format wrong. Hence I think we should try to improve the description of the report format, with examples, to make it easier to explain to people how to get the format right. I do not think we should change the spec. As chair, I agree with John here: we have the document on our queue and we should wrap it up and get it out. But we should not spend a great deal of time on it. Ale, are you ready to do the edits and move it forward? Or would you prefer to have someone else take it over? What's your thought on getting it finished with a small bit of effort? I added an example, see https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-failure-reporting/blob/main/draft-ietf-dmarc-failure-reporting-04.txt#L528 I omit diffs, as the only difference is Appendix A.3 (and I removed an antique Acknowledgments section). I just picked a report I received and anonymized it. How is it? Corrections, fixes and hints welcome. 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
Chair here... > On Tue, 9 Aug 2022, Murray S. Kucherawy wrote: > > I agree with John, I think, that the amount of time we should spend > > improving failure reporting should be proportional to how much it's used, > > or how much the community is asking us to do so. ... > > My small mail system gets failure reports every day, sometimes just two or > three, sometimes several dozen, generally depending on how much mail I've > sent to large lists like NANOG or ietf@ietf. Mike tells us that there's > reports we don't see, sent by private agreement. > > I think that's enough that we should leave it in. I also see a fair > number of reports in wrong format, a consistent wrong format starting with > "A message claiming to be from you has failed the published DMARC > policy for your domain." from at least two reporters which tells me that > there is a DMARC implementation that got the format wrong. > > Hence I think we should try to improve the description of the report > format, with examples, to make it easier to explain to people how to get > the format right. I do not think we should change the spec. As chair, I agree with John here: we have the document on our queue and we should wrap it up and get it out. But we should not spend a great deal of time on it. Ale, are you ready to do the edits and move it forward? Or would you prefer to have someone else take it over? What's your thought on getting it finished with a small bit of effort? Barry ___ 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 Tue, 9 Aug 2022, Murray S. Kucherawy wrote: I agree with John, I think, that the amount of time we should spend improving failure reporting should be proportional to how much it's used, or how much the community is asking us to do so. ... My small mail system gets failure reports every day, sometimes just two or three, sometimes several dozen, generally depending on how much mail I've sent to large lists like NANOG or ietf@ietf. Mike tells us that there's reports we don't see, sent by private agreement. I think that's enough that we should leave it in. I also see a fair number of reports in wrong format, a consistent wrong format starting with "A message claiming to be from you has failed the published DMARC policy for your domain." from at least two reporters which tells me that there is a DMARC implementation that got the format wrong. Hence I think we should try to improve the description of the report format, with examples, to make it easier to explain to people how to get the format right. I do not think we should change the spec. 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] Collecting message metadata, was Time to work on failure reporting
On Wed 10/Aug/2022 06:45:04 +0200 Scott Kitterman wrote: On Tuesday, August 9, 2022 11:57:53 PM EDT Murray S. Kucherawy wrote: On Tue, Aug 9, 2022 at 7:54 AM Dotzero wrote: When "we" (dmarc.org team) originally came up with DMARC, the goal was to take what was in essence a private club to an open standard that anyone could benefit from. My personal take is that validators choose not to provide failure reporting for various reasons other than "it's a noise generator". It requires extra effort and resources that some validators choose not to undertake because it doesn't benefit them (from their perspective). Another reason some validators don't implement is fear of potential liability under GDPR or similar regimes. There are a number of validators that provide failure reports through private channels but only where a direct or indirect contractual relationship exists. This seems to primarily through intermediaries that provide email authentication services. My recollection is similar. When DKIM was young, it was very valuable to be able to get two implementations to cooperate when debugging validation failures. Specifically, to debug a failed signature, you need the blobs of data that were fed to each of the hashes from both the signer and the verifier so they can be compared. That means the verifier has to keep those things around, and when something fails to verify, it needs to dig them up and send them back to the signer. RFC 6651 is the published version of something that originally appeared as a private feature of OpenDKIM, whose roots go all the way back to the first interoperability event (~2005) where the ability to close these loops was hugely impactful at working out the kinks. In essence, it allows you to include a signal in your DKIM signatures that you want this data to be sent back to you if the receiver is willing to participate. This same technique was useful when developing and testing an open source ARC implementation. I don't think there was widespread implementation of what that RFC describes, but it is an early version of the theme that led to the forensic reports in DMARC. For DMARC, the intent was similar: If my mail is landing someplace and failing to validate, I would love to know why, and maybe you're willing to help me out by providing me with that information without me having to ask you to scrape logs and/or do other local sleuthing to find the problem. For an operator just experimenting with it to gauge potential impact of turning it on fully, or to shake out the bugs in a new implementation, it's quite valuable. But yes, it risks revealing all kinds of stuff and ultimately shouldn't be left "on" once the thing is fully in production. That doesn't seem to be the current usage. People seem to just set ruf= in their record and leave it there for ever. How about returning the full message/rfc822 of failed messages only when the Subject: matches "This is a test"? Back then we were more interested in getting DKIM and eventually DMARC working, and privacy wasn't as much of a consideration as it is now. (Note, for example, that both versions of DKIM and RFC 6651 pre-date RFC 6973, wherein the IETF formalized the idea of a Privacy Considerations section.) I agree with John, I think, that the amount of time we should spend improving failure reporting should be proportional to how much it's used, or how much the community is asking us to do so. If the consensus is to drop it, then we should say, probably in an appendix, that original DMARC had this, but nobody used it and it's a PII nightmare, so it's no longer supported in the Standards Track version. I think it would be useful to review RFC 6973 and see if we think feedback reports as currently defined are consistent with it, but I don't think we should spend a lot of time on revisions. I would guess there are, in general terms, only three answers: 1. It's fine, no worries. 2. It's not fine, but can be made fine with tweaks. 4. It's not fine and needs a major overhaul, so maybe we dump it. Given RFC 6973, I think we owe the IESG spending a little time to assess if there is an issue or not. It would be useful, I think, for the shepherd write up to be able to say that since the input specification was pre-RFC 6973, we did an assessment in the working group and documented the appropriate privacy considerations/made some tweaks as a result. RFC 6973 deserves being referenced. Redacting all addresses (including Received:'s for clause) can be mandated. Something like search the whole header for '@' followed by a known domain and replace the local part. 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 Tuesday, August 9, 2022 11:57:53 PM EDT Murray S. Kucherawy wrote: > On Tue, Aug 9, 2022 at 7:54 AM Dotzero wrote: > > When "we" (dmarc.org team) originally came up with DMARC, the goal was to > > take what was in essence a private club to an open standard that anyone > > could benefit from. My personal take is that validators choose not to > > provide failure reporting for various reasons other than "it's a noise > > generator". It requires extra effort and resources that some validators > > choose not to undertake because it doesn't benefit them (from their > > perspective). Another reason some validators don't implement is fear of > > potential liability under GDPR or similar regimes. There are a number of > > validators that provide failure reports through private channels but only > > where a direct or indirect contractual relationship exists. This seems to > > primarily through intermediaries that provide email authentication > > services. > My recollection is similar. When DKIM was young, it was very valuable to > be able to get two implementations to cooperate when debugging validation > failures. Specifically, to debug a failed signature, you need the blobs of > data that were fed to each of the hashes from both the signer and the > verifier so they can be compared. That means the verifier has to keep > those things around, and when something fails to verify, it needs to dig > them up and send them back to the signer. RFC 6651 is the published > version of something that originally appeared as a private feature of > OpenDKIM, whose roots go all the way back to the first interoperability > event (~2005) where the ability to close these loops was hugely impactful > at working out the kinks. In essence, it allows you to include a signal in > your DKIM signatures that you want this data to be sent back to you if the > receiver is willing to participate. This same technique was useful when > developing and testing an open source ARC implementation. > > I don't think there was widespread implementation of what that RFC > describes, but it is an early version of the theme that led to the forensic > reports in DMARC. For DMARC, the intent was similar: If my mail is landing > someplace and failing to validate, I would love to know why, and maybe > you're willing to help me out by providing me with that information without > me having to ask you to scrape logs and/or do other local sleuthing to find > the problem. > > For an operator just experimenting with it to gauge potential impact of > turning it on fully, or to shake out the bugs in a new implementation, it's > quite valuable. But yes, it risks revealing all kinds of stuff and > ultimately shouldn't be left "on" once the thing is fully in production. > Back then we were more interested in getting DKIM and eventually DMARC > working, and privacy wasn't as much of a consideration as it is now. > (Note, for example, that both versions of DKIM and RFC 6651 pre-date RFC > 6973, wherein the IETF formalized the idea of a Privacy Considerations > section.) > > I agree with John, I think, that the amount of time we should spend > improving failure reporting should be proportional to how much it's used, > or how much the community is asking us to do so. If the consensus is to > drop it, then we should say, probably in an appendix, that original DMARC > had this, but nobody used it and it's a PII nightmare, so it's no longer > supported in the Standards Track version. I think it would be useful to review RFC 6973 and see if we think feedback reports as currently defined are consistent with it, but I don't think we should spend a lot of time on revisions. I would guess there are, in general terms, only three answers: 1. It's fine, no worries. 2. It's not fine, but can be made fine with tweaks. 4. It's not fine and needs a major overhaul, so maybe we dump it. Given RFC 6973, I think we owe the IESG spending a little time to assess if there is an issue or not. It would be useful, I think, for the shepherd write up to be able to say that since the input specification was pre-RFC 6973, we did an assessment in the working group and documented the appropriate privacy considerations/made some tweaks as a result. 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
On Tue, Aug 9, 2022 at 7:54 AM Dotzero wrote: > When "we" (dmarc.org team) originally came up with DMARC, the goal was to > take what was in essence a private club to an open standard that anyone > could benefit from. My personal take is that validators choose not to > provide failure reporting for various reasons other than "it's a noise > generator". It requires extra effort and resources that some validators > choose not to undertake because it doesn't benefit them (from their > perspective). Another reason some validators don't implement is fear of > potential liability under GDPR or similar regimes. There are a number of > validators that provide failure reports through private channels but only > where a direct or indirect contractual relationship exists. This seems to > primarily through intermediaries that provide email authentication services. > My recollection is similar. When DKIM was young, it was very valuable to be able to get two implementations to cooperate when debugging validation failures. Specifically, to debug a failed signature, you need the blobs of data that were fed to each of the hashes from both the signer and the verifier so they can be compared. That means the verifier has to keep those things around, and when something fails to verify, it needs to dig them up and send them back to the signer. RFC 6651 is the published version of something that originally appeared as a private feature of OpenDKIM, whose roots go all the way back to the first interoperability event (~2005) where the ability to close these loops was hugely impactful at working out the kinks. In essence, it allows you to include a signal in your DKIM signatures that you want this data to be sent back to you if the receiver is willing to participate. This same technique was useful when developing and testing an open source ARC implementation. I don't think there was widespread implementation of what that RFC describes, but it is an early version of the theme that led to the forensic reports in DMARC. For DMARC, the intent was similar: If my mail is landing someplace and failing to validate, I would love to know why, and maybe you're willing to help me out by providing me with that information without me having to ask you to scrape logs and/or do other local sleuthing to find the problem. For an operator just experimenting with it to gauge potential impact of turning it on fully, or to shake out the bugs in a new implementation, it's quite valuable. But yes, it risks revealing all kinds of stuff and ultimately shouldn't be left "on" once the thing is fully in production. Back then we were more interested in getting DKIM and eventually DMARC working, and privacy wasn't as much of a consideration as it is now. (Note, for example, that both versions of DKIM and RFC 6651 pre-date RFC 6973, wherein the IETF formalized the idea of a Privacy Considerations section.) I agree with John, I think, that the amount of time we should spend improving failure reporting should be proportional to how much it's used, or how much the community is asking us to do so. If the consensus is to drop it, then we should say, probably in an appendix, that original DMARC had this, but nobody used it and it's a PII nightmare, so it's no longer supported in the Standards Track version. -MSK, participating ___ 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 Tue, Aug 9, 2022 at 6:17 AM Ken O'Driscoll wrote: > > > > Any hint about why it's not used? > > > > PII. Report generators are reluctant to send reports that may contain PII > for compliance, security, and privacy reasons. > > Plus, if you are a report receiver those reasons may be valid too. What's > the point in requesting failure reports if your email ops people are > prohibited from actually reading them etc. > > I don't think their use is ever going to grow and will probably further > decline over the years. > > Keeping it as-is for backwards compatibility is probably the best option. > I'm not sure that it's necessary to keep it as is for backward compatibility. Both RFC 7489 and DMARCbis contain the phrase "unknown tags MUST be ignored" in the General Record Format text, so even if DMARCbis were to strike the 'ruf' tag and the concept of failure reporting entirely, it shouldn't break anything for compliant legacy or updated implementations. -- *Todd Herr * | Technical Director, Standards and Ecosystem *e:* todd.h...@valimail.com *m:* 703.220.4153 This email and all data transmitted with it contains confidential and/or proprietary information intended solely for the use of individual(s) authorized to receive it. If you are not an intended and authorized recipient you are hereby notified of any use, disclosure, copying or distribution of the information included in this transmission is prohibited and may be unlawful. Please immediately notify the sender by replying to this email and then delete it from your system. ___ 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 Mon, Aug 8, 2022 at 4:14 AM Alessandro Vesely wrote: > On Sun 07/Aug/2022 19:20:12 +0200 John Levine wrote: > >>> 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. > > > Right, that's to be defined. Clearly, the criteria differ between SPF and > DKIM. We could also define fuzzy criteria. > > > > 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. > > > Does "not to do this" refer to failure reporting as a whole? > > As is, it is a noise generator that the majority of users decided not to > implement. > When "we" (dmarc.org team) originally came up with DMARC, the goal was to take what was in essence a private club to an open standard that anyone could benefit from. My personal take is that validators choose not to provide failure reporting for various reasons other than "it's a noise generator". It requires extra effort and resources that some validators choose not to undertake because it doesn't benefit them (from their perspective). Another reason some validators don't implement is fear of potential liability under GDPR or similar regimes. There are a number of validators that provide failure reports through private channels but only where a direct or indirect contractual relationship exists. This seems to primarily through intermediaries that provide email authentication services. Michael Hammer > > > 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
> > Any hint about why it's not used? > PII. Report generators are reluctant to send reports that may contain PII for compliance, security, and privacy reasons. Plus, if you are a report receiver those reasons may be valid too. What's the point in requesting failure reports if your email ops people are prohibited from actually reading them etc. I don't think their use is ever going to grow and will probably further decline over the years. Keeping it as-is for backwards compatibility is probably the best option. Ken. ___ 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 Mon 08/Aug/2022 14:10:53 +0200 John Levine wrote: On Mon, 8 Aug 2022, Alessandro Vesely wrote: 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. Does "not to do this" refer to failure reporting as a whole? As is, it is a noise generator that the majority of users decided not to implement. We can see what the group thinks. But it surely would be foolish to spend our limited time trying to define a complex and unworkable redesign of a feature hardly anyone uses. IMHO, we should either improve the feature or drop it. Any hint about why it's not used? 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 Mon, 8 Aug 2022, Alessandro Vesely wrote: It also misses the fact that "already reported characteristics" is undefined. Right, that's to be defined. Clearly, the criteria differ between SPF and DKIM. We could also define fuzzy criteria. Mike and I just provided separate reasons why that is both a bad idea and not even possible. 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. Does "not to do this" refer to failure reporting as a whole? As is, it is a noise generator that the majority of users decided not to implement. We can see what the group thinks. But it surely would be foolish to spend our limited time trying to define a complex and unworkable redesign of a feature hardly anyone uses. 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] Collecting message metadata, was Time to work on failure reporting
On Sun 07/Aug/2022 19:20:12 +0200 John Levine wrote: 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. Right, that's to be defined. Clearly, the criteria differ between SPF and DKIM. We could also define fuzzy criteria. 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. Does "not to do this" refer to failure reporting as a whole? As is, it is a noise generator that the majority of users decided not to implement. 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
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] 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] 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
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. R's, John ___ 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 Fri 05/Aug/2022 18:33:29 +0200 John Levine wrote: It appears that Alessandro Vesely said: On Wed 03/Aug/2022 21:52:21 +0200 John Levine wrote: He insists that the failure reports mean something is wrong, the list needs to make them go away, which of course means rewriting headers to make it harder to tell who each message was from. I suggested that if he doesn't want the reports he's asking for he should not ask for them, or perhaps use a three line procmail script to sort the obviously benign list ones, but he's sure it's the list's fault. For aggregate reports, one has to collect the information that will later be aggregated. Failure reporting apparently requires no data collection, which is probably wrong. 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. If it were up to me, I would completely remove failure reports from the spec. Few people send them, they're not very useful, they have horrible privacy problems, and as we have seen people use them as yet another stick to beat up innocent mailing lists. +1, let's drop it! 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
It appears that Alessandro Vesely said: >On Wed 03/Aug/2022 21:52:21 +0200 John Levine wrote: >> He insists that the failure reports mean something is wrong, the list needs >> to make them go away, which of course means rewriting headers to make it >> harder >> to tell who each message was from. I suggested that if he doesn't want the >> reports he's asking for he should not ask for them, or perhaps use a three >> line procmail script to sort the obviously benign list ones, but he's sure >> it's the list's fault. > >For aggregate reports, one has to collect the information that will later >be aggregated. Failure reporting apparently requires no data collection, >which is probably wrong. 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. >Should we specify what data to collect? No. >Would that worsen the perceived privacy violations? Since we cannot read people's minds and guess what they perceive as privacy violations, there is no way to answer this question. >Should we specify a max amount / percentage of reports per domain? PLEASE can we not invent yet more irrelevant distractions. If it were up to me, I would completely remove failure reports from the spec. Few people send them, they're not very useful, they have horrible privacy problems, and as we have seen people use them as yet another stick to beat up innnocent mailing lists. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
