Re: [dmarc-ietf] Report bombing is a prolem, Forensic report loops are not
On Tue, 2 Feb 2021, Alessandro Vesely wrote: Whatever mechanisms are used, servers MUST contain provisions for detecting and stopping trivial loops. I can tell you from bitter experience that rate limiting is the *ONLY* reliable way to stop trivial loops. Whatever else you try, something will eventually change or delete the thing you try to use to recognize loops. As a concrete example, I get a lot of failure reports from antispamcloud.com which are not multipart/report and which software would not recognize as a failure report. Nonetheless, if they got into a reporting loop, it would be annoying, and rate limiting would stop them. Mailbombing in general is not a loop. Two report generators reporting each other's failure to authenticate a failure report /is/ a loop. Sometimes mailbombing is a loop, sometimes it isn't. If the loop is so slow that it doesn't trigger rate limits, it's not likely to be a practical problem. 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] Report bombing is a prolem, Forensic report loops are not
On Mon 01/Feb/2021 17:29:23 +0100 John R Levine wrote: 3.3. Transport Email streams carrying DMARC failure reports MUST conform to the DMARC mechanism, thereby resulting in an aligned "pass". Special care must be taken of authentication, as failure to authenticate failure reports may result in mail loops. Reporters SHOULD rate limit the number of failure reports sent to any recipient to avoid overloading recipient systems. Not MUST? You might have other ways to prevent mailbombing, e.g., only sending failure reports to people who you know have bigger mail systems than you do. Right. However, Murray recalled Section 6.3 of SMTP: Whatever mechanisms are used, servers MUST contain provisions for detecting and stopping trivial loops. Mailbombing in general is not a loop. Two report generators reporting each other's failure to authenticate a failure report /is/ a loop. So it deserves a MUST. Perhaps: Reporters SHOULD rate limit the number of failure reports sent to any recipient to avoid overloading recipient systems. In addition, reporters MUST ensure that such rate limiting or any other means can effectively stop possible mail loops. ? Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Report bombing is a prolem, Forensic report loops are not
On Sun, Jan 31, 2021 at 3:02 PM John Levine wrote: > In article <49b248dc-91a7-7f2d-ba28-72fe8d6d3...@tana.it> you write: > >Rate limiting usually implies a number of buckets. They are managed by > >imposing limits per time periods, which can be either server-global or > per > >bucket. Normally, for MSA usage, one has one bucket per user. I have > never > >implemented failure reporting, but I'd guess buckets may vary. Besides > the > >signing domain (which determines the report consumer), the receiving > address, > >the sender and the spam flag may deserve their own buckets. > > The only one that matters for DMARC reporting is the recipient > address, since the purpose of rate limiting is to avoid overloading > the recipient mail system. I wouldn't worry about trying to send a > "representative" set of reports. > > Keep in mind that very few people send failure reports at all. > My experience is that most failure reports are provided through private channels where there are contractual agreements in place to deal with potential privacy and legal issues. This may be through intermediaries or direct between the parties (sending organization and receiving organization). Understand that the DMARC effort came about because the original participants felt it was useful in the private exchange of information between senders and receivers. We felt it was better as an open standard rather than as a private club. >From my perspective it is unfortunate that we can't seem to find a way to implement a system where failure reports are available other than through private channels. In my > experience few of them are useful. Most of mine are ordinary mailing > list messages where the failure is not surprising and does not mean > that anything needs to be fixed. > I disagree with John about failure reports not being useful. I have found failure reports to be extremely useful in anti-abuse efforts. The value can range from takedowns of images and links to maliciousness to shutting down sources of maliciousness.In some cases it has proven useful to law enforcement as documentation of activities. Unfortunately, I think addressing some of this has to be beyond the scope of the current effort. Michael Hammer ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Report bombing is a prolem, Forensic report loops are not
3.3. Transport Email streams carrying DMARC failure reports MUST conform to the DMARC mechanism, thereby resulting in an aligned "pass". Special care must be taken of authentication, as failure to authenticate failure reports may result in mail loops. Reporters SHOULD rate limit the number of failure reports sent to any recipient to avoid overloading recipient systems. Not MUST? You might have other ways to prevent mailbombing, e.g., only sending failure reports to people who you know have bigger mail systems than you 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] Report bombing is a prolem, Forensic report loops are not
On Sun 31/Jan/2021 21:02:38 +0100 John Levine wrote: In article <49b248dc-91a7-7f2d-ba28-72fe8d6d3...@tana.it> you write: Rate limiting usually implies a number of buckets. They are managed by imposing limits per time periods, which can be either server-global or per bucket. Normally, for MSA usage, one has one bucket per user. I have never implemented failure reporting, but I'd guess buckets may vary. Besides the signing domain (which determines the report consumer), the receiving address, the sender and the spam flag may deserve their own buckets. The only one that matters for DMARC reporting is the recipient address, since the purpose of rate limiting is to avoid overloading the recipient mail system. I wouldn't worry about trying to send a "representative" set of reports. Keep in mind that very few people send failure reports at all. True, it's not worth suggesting a super duper rate limiting. Committed text: 3.3. Transport Email streams carrying DMARC failure reports MUST conform to the DMARC mechanism, thereby resulting in an aligned "pass". Special care must be taken of authentication, as failure to authenticate failure reports may result in mail loops. Reporters SHOULD rate limit the number of failure reports sent to any recipient to avoid overloading recipient systems. Not MUST? Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Report bombing is a prolem, Forensic report loops are not
In article <49b248dc-91a7-7f2d-ba28-72fe8d6d3...@tana.it> you write: >Rate limiting usually implies a number of buckets. They are managed by >imposing limits per time periods, which can be either server-global or per >bucket. Normally, for MSA usage, one has one bucket per user. I have never >implemented failure reporting, but I'd guess buckets may vary. Besides the >signing domain (which determines the report consumer), the receiving address, >the sender and the spam flag may deserve their own buckets. The only one that matters for DMARC reporting is the recipient address, since the purpose of rate limiting is to avoid overloading the recipient mail system. I wouldn't worry about trying to send a "representative" set of reports. Keep in mind that very few people send failure reports at all. In my experience few of them are useful. Most of mine are ordinary mailing list messages where the failure is not surprising and does not mean that anything needs to be fixed. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Report bombing is a prolem, Forensic report loops are not
On Sat 30/Jan/2021 13:51:56 +0100 Douglas Foster wrote: Interesting point. [...] The spec is confusing because it says (a) failure reports should be sent immediately, (b) failure reports should be aggregated, and (c) failure reports should be throttled but without specifying a limit. I wonder if the rule should be one message per week per source, since any large volume sender will be getting reports from multiple sources. The main problem with this is that law enforcement actions may want to be bombed. This point deserves its own ticket. While we have a ri= tag (to be revised, see Tickets #50 and #71) and !size limits for aggregate reports, failure report consumers don't have a way to express the amount or frequency of feedback they want. On Fri, Jan 29, 2021 at 4:00 PM John Levine wrote: In article you write: 3.3. Transport Email streams carrying DMARC failure reports MUST conform to the DMARC mechanism, thereby resulting in an aligned "pass". Special care must be taken of authentication, as failure to authenticate failure reports may provoke further reports. Reporters SHOULD rate limit the number of failure reports sent to any recipient to avoid overloading recipient systems. I haven't yet modified this, but I mostly agree. Why would reports due to a mail loop be more of a problem than due to some random spammer sending a lot of fake mail, or (real life) your users send mail to mailing lists with thousands of subscribers? Rate limit your reports, don't worry about where they came from. Rate limiting usually implies a number of buckets. They are managed by imposing limits per time periods, which can be either server-global or per bucket. Normally, for MSA usage, one has one bucket per user. I have never implemented failure reporting, but I'd guess buckets may vary. Besides the signing domain (which determines the report consumer), the receiving address, the sender and the spam flag may deserve their own buckets. Thoughts? Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Report bombing is a prolem, Forensic report loops are not
Interesting point. In your experience, how often does reporting produce any change in sender behavior? I have made attempts both to help senders correct their own SPF or DMARC policy, or to get them to stop violating my DMARC policy. As best I can recall, my success rate has been zero. For a responsive organization, finding a problem and getting the change approved is likely to be a time-consuming a quick process. A week turnaround would seem timely, unless they go into emergency mode because lots of mail is being blocked. The spec is confusing because it says (a) failure reports should be sent immediately, (b) failure reports should be aggregated, and (c) failure reports should be throttled but without specifying a limit. Of course, if the cause is a spammer, there is nothing that the domain owner can do at all. I wonder if the rule should be one message per week per source, since any large volume sender will be getting reports from multiple sources. The main problem with this is that law enforcement actions may want to be bombed. DF On Fri, Jan 29, 2021 at 4:00 PM John Levine wrote: > In article you write: > >3.3. Transport > > > >Email streams carrying DMARC failure reports MUST conform to the > >DMARC mechanism, thereby resulting in an aligned "pass". Special > >care must be taken of authentication, as failure to authenticate > >failure reports may provoke further reports. > > Reporters SHOULD rate limit the number of failure reports sent > to any recipient to avoid overloading recipient systems. > > > Why would reports due to a mail loop be more of a problem than due to > some random spammer sending a lot of fake mail, or (real life) your > users send mail to mailing lists with thousands of subscribers? Rate > limit your reports, don't worry about where they came from. > > 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] Report bombing is a prolem, Forensic report loops are not
In article you write: >3.3. Transport > >Email streams carrying DMARC failure reports MUST conform to the >DMARC mechanism, thereby resulting in an aligned "pass". Special >care must be taken of authentication, as failure to authenticate >failure reports may provoke further reports. Reporters SHOULD rate limit the number of failure reports sent to any recipient to avoid overloading recipient systems. Why would reports due to a mail loop be more of a problem than due to some random spammer sending a lot of fake mail, or (real life) your users send mail to mailing lists with thousands of subscribers? Rate limit your reports, don't worry about where they came from. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
