Re: [dmarc-ietf] p=quarantine
On 12/11/2020 11:19 AM, Dotzero wrote:> On Fri, Dec 11, 2020 at 11:11 AM Hector Santos We are not doing reporting at this time. Not the main focus. That can come later as an augmented feature, in fact, we might consider it as a paid service to be sending thousands report out to domains. That's good community spirit. eh, thanks? I doubt many would be willing to pay you for your reports. Customers are already paying for the total platform (not open source, not free, its expensive commercial hosting software). It comes without any DMARC reporting except with the description to add DMARC report tags to collect the reports and instructions to redirect the notifications to specific admin-only mail areas. No Doubt, this is an easy added-value feature when we are ready to offer the ad-hoc reporting capability added to their existing Wildcat! Ad-hoc Reporting tools (an paid for add-on). How do you benefit from DMARC? What is your rejection (or protect domain action) average? Do you allow subscriptions to your mailing list services or you do rewriting? -- Hector Santos, https://secure.santronics.com https://twitter.com/hectorsantos ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] [EXTERNAL] Re: Clarification of Subdomain Reporting
On Fri, 11 Dec 2020, Brotman, Alex wrote: That's a somewhat incompatible change, so I'd want to be sure we agree that it's a real problem that's worth changing the report format. I suppose if we do we should encourage report consumers to be prepared for old and new formats. The goal was to clarify the language, without (to the best of our ability) changing the schema. I'd welcome a other attempts at clarifications (if you believe mine introduces structural XML changes). So it'd say yeah, we know the XML lets you put multiple header_from domains in the same report row, but please don't do that, send a separate report row for each header_from? I suppose that could work. R's, John Old: New: 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] [EXTERNAL] Re: Clarification of Subdomain Reporting
> -Original Message- > From: John Levine > Sent: Friday, December 11, 2020 2:39 PM > To: dmarc@ietf.org > Cc: Brotman, Alex > Subject: [EXTERNAL] Re: [dmarc-ietf] Clarification of Subdomain Reporting > > In article > 11.prod.outlook.com> you write: > >Based on a discussion from last year > >(https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/dmar > >c/YoHhhaAfwRjbd8aq4fiV6xU1ifw/__;!!CQl3mcHX2A!WeJ2k0NWH5mMH3xZ4 > m50qgan4LKX-1dJkG9EIbOpAQShq9B1mQP7uwFLByCaECBQ7Ypo$ ), there was > a request/ticket to clarify the language in the document. > > > >>From > https://urldefense.com/v3/__https://tools.ietf.org/html/rfc7489*section- > 7.2__;Iw!!CQl3mcHX2A!WeJ2k0NWH5mMH3xZ4m50qgan4LKX- > 1dJkG9EIbOpAQShq9B1mQP7uwFLByCaEErMUwqg$ : > > > > * Data for each Domain Owner's subdomain separately from mail from > > the sender's Organizational Domain, even if there is no explicit > > subdomain policy > > That would be a change to the XML report schema. It'd change as I show below > to force a separate row for each header_from. > > That's a somewhat incompatible change, so I'd want to be sure we agree that > it's a real problem that's worth changing the report format. I suppose if we > do > we should encourage report consumers to be prepared for old and new formats. The goal was to clarify the language, without (to the best of our ability) changing the schema. I'd welcome a other attempts at clarifications (if you believe mine introduces structural XML changes). > > R's, > John > > > > > >minOccurs="0"/> > >minOccurs="1"/> > Old: > >minOccurs="1"/> > > New: > > > > > ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Clarification of Subdomain Reporting
In article you write: >Based on a discussion from last year >(https://mailarchive.ietf.org/arch/msg/dmarc/YoHhhaAfwRjbd8aq4fiV6xU1ifw/), >there was a >request/ticket to clarify the language in the document. > >>From https://tools.ietf.org/html/rfc7489#section-7.2: > > * Data for each Domain Owner's subdomain separately from mail from > the sender's Organizational Domain, even if there is no explicit > subdomain policy That would be a change to the XML report schema. It'd change as I show below to force a separate row for each header_from. That's a somewhat incompatible change, so I'd want to be sure we agree that it's a real problem that's worth changing the report format. I suppose if we do we should encourage report consumers to be prepared for old and new formats. R's, John Old: New: ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
[dmarc-ietf] Clarification of Subdomain Reporting
Based on a discussion from last year (https://mailarchive.ietf.org/arch/msg/dmarc/YoHhhaAfwRjbd8aq4fiV6xU1ifw/), there was a request/ticket to clarify the language in the document. >From https://tools.ietf.org/html/rfc7489#section-7.2: * Data for each Domain Owner's subdomain separately from mail from the sender's Organizational Domain, even if there is no explicit subdomain policy Seems to be lacking clarity. I took an initial attempt at clarifying that bullet, but welcome comments: * Within the same report, subdomain data should be separate from data for the Sender's Organizational Domain. This should be true even when subdomain does not have their own explicit DMARC record Does that seem reasonable? I'd suspect we should modify the sample report to include a subdomain as well. -- Alex Brotman Sr. Engineer, Anti-Abuse & Messaging Policy Comcast ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] dmarc - New Meeting Session Request for IETF 110
On Fri, Dec 11, 2020 at 9:56 AM Michael Thomas wrote: > I know this is the wrong list, but what about people who could afford it, > but don't want to afford it? It's not like I'm making money from > participating and that it's just a cost of doing business. These > discussions ran into the trillions of messages on the ietf list so i was > never able to figure that part out. > To answer your question, I'll offer this text which was on the fee waiver page for IETF 109, but you're right that this is really off-topic here so further discussion should be started on i...@ietf.org. "We understand that not everyone can afford the IETF 109 registration fee for a variety of reasons, including issues with income, employment status and employer support, and we do not want any of these to be a barrier to participation. If you cannot afford the registration fee then please take this fee waiver option to ensure that you can participate. We make an unlimited number of fee waivers available and we do not ask you to explain why you are taking the fee waiver option or make any check on eligibility as we operate on a trust basis. The information you provide will be confidential and will only be used for the purpose of allocating fee waivers." -MSK, ART AD ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] dmarc - New Meeting Session Request for IETF 110
On 12/11/20 9:49 AM, Murray S. Kucherawy wrote: I concur. The fee for virtual meetings is less than half that of the usual in-person meetings since the IETF's costs are obviously lower, but we do need to keep the lights on. For people that can't afford to participate otherwise, there is a fee waiver program available. I know this is the wrong list, but what about people who could afford it, but don't want to afford it? It's not like I'm making money from participating and that it's just a cost of doing business. These discussions ran into the trillions of messages on the ietf list so i was never able to figure that part out. Mike ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] dmarc - New Meeting Session Request for IETF 110
On 12/11/2020 9:49 AM, Murray S. Kucherawy wrote: I suggest that this working group has enough of a work queue before it that having both an interim meeting and a scheduled session at IETF 110 is certainly worth considering. +1 Interims should be saved for times the wg has hit a wall in making progress and needs the greater communication efficiencies of real-time interaction. d/ -- Dave Crocker dcroc...@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter American Red Cross dave.crock...@redcross.org ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] dmarc - New Meeting Session Request for IETF 110
On Fri, Dec 11, 2020 at 8:59 AM Alexey Melnikov wrote: > Murray will correct me if I am wrong, but I have several comments: > > On Fri, Dec 11, 2020, at 12:37 AM, Kurt Andersen (b) wrote: > > I'm wondering why we should wait for IETF110 rather than having an interim > meeting sooner. Interim meetings are also likely to garner greater > participation since they do not include participation fee. If there are > topics worthy of F2F discussion, why wait? If there are not, then why > charge people to join a pointless meeting? > > 1). All online IETFs this year had "free attendence" option. If people can > afford to pay to attend, they should, as this supports RFC publication > cost, cost of online meetings, etc. But people can attend for free if needs > be. > As far as I know this is going to be the case for IETF 110. > I concur. The fee for virtual meetings is less than half that of the usual in-person meetings since the IETF's costs are obviously lower, but we do need to keep the lights on. For people that can't afford to participate otherwise, there is a fee waiver program available. I suggest that this working group has enough of a work queue before it that having both an interim meeting and a scheduled session at IETF 110 is certainly worth considering. -MSK, ART AD ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] p=quarantine
In article <1ac986ff-507b-4917-9c6d-d84e9337f...@wordtothewise.com> you write: >p=none: mail sent by authorized users of this domain may or may not be aligned >in a DMARC compliant way. > >p=quarantine: mail sent by authorized users of this domain should be aligned >in a DMARC compliant >way. Mail that is unaligned may or may not be legitimate messages from this >organization. So far so good. >p=reject: all mail sent from this domain should be aligned in a DMARC >compliant way. Mail that is >unaligned is not authorized by the domain owner and may be discarded or >rejected by the recipient. Naah. p=reject: all mail sent from this domain should be aligned in a DMARC compliant way. We believe that unaligned mail is from unauthorized senders so we ask receivers to reject it, even though that might mean some of our authorized senders' mail is rejected too. R's, John PS: I had more or less this same discussion leading to ADSP discardable. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Ticket #61 - Define and add a simplified (redacted) failure report
On 12/11/20 7:48 AM, Alessandro Vesely wrote: > On Thu 10/Dec/2020 17:59:54 +0100 Jesse Thompson wrote: >> On 12/9/20 10:28 PM, seth wrote: >>> As an individual, I feel extremely strongly that failure reports should go >>> away in their entirety. Although Jesse Thompson has outlined a use case >>> that really has no other good solution, and is equally true in other large >>> complicated organizations. >> >> To be clear, I'm not advocating for this From/To use case, but I know of >> universities who would. There's at least one who cleverly flattened their >> SPF record to include every known sender specifically because they had no >> mission to change the way their institution distributively sends email. >> That is the type of organization who *may* want From/To data, assuming they >> want to do more validation before adding yet another IP to their SPF. It's >> a stretch in my mind. > > > I'm not clear whether you're talking about sending or receiving reports. > Received: chains are key for evaluating addresses to add to SPF records. I > don't think it makes sense to specify their omission from Only the last hop from the receiver's viewpoint is really needed for a domain owner to assess gaps in SPF. That's already addressed with aggregate reports. What's missing is the additional context that the failure reports are intended to provide, to help domain owners determine if the IP address which sent the message was legitimate. Of course, received chains are helpful for troubleshooting. There's no "right" answer regarding the balance of useful information vs privacy, so I'm suggesting that we put things like this on a spectrum of usefulness/privacy-concerning. > My guess at why an organization may want to send only From/To rather than a > possibly redacted text/rfc822-headers are as follows: > > * It is too hard for them to asses the risk of including unknown header > fields, yet they must do it before enabling ruf, > > * the software they use doesn't have an option to redact PII, or (unlikely) > > * they try to save bandwidth and disk space by reducing that ghastly pile of > freaky fields that infest message headers these days. If sending only a limited amount of information is considered an acceptable alternative to full/unredacted information, it might help encourage these organizations to send failure reports, perhaps? >> I would only strongly advocate for seeing the unredacted From header, since >> my primary concern was with identifying a little bit more information about >> who was using the domain and why (i.e. who is using random ESP). > > > Agreed. > > >> The stated purpose of Failure Reports is "for quickly notifying the Domain >> Owners when there is an authentication failure ... also provide more >> information about the failed message than is available in an aggregate >> report". Since the focus of DMARC is to authorize the use of the domain >> used in the From header, then the logical next incremental levels of "more >> information" should be: >> >> 1) From header domain (already known) >> 2) local part of From address >> 3) Friendly From >> 4) Subject >> 5) other parts of the message containing identifiable information >> >> 1->5 decreases in usefulness/relevancy to DMARC >> 1->5 increases in unnecessary information disclosure > > > The mail filter I do sends aggregate reports but not failure reports. Should > I add it? I'm thinking I could frame it like so: > > * Have a global flag to enable or disable ruf's, which can be overridden on a > per-domain basis. Default to disabled. > > * The flag can specify three confidentiality levels: > - full message > - header only > - header only + redact. > > * Redacting the header would work as follows: > 1. Collect recipients addresses in To:, Cc:, and envelope, > 2. compute the rfc6590-redacted version of each address, > 3. for all fields, replace any occurrence with the redacted version. > > * Reports are left in a user-configured directory, assuming that a user > supplied script deals with them. > > Does that make sense? > > Should dmarc-failure-reporting include text with practical suggestions along > those lines? Does this redaction logic apply to the From header too? If so, I would recommend adding a fourth confidentiality flag for reporters who want to redact recipient information but leave the From header unredacted to better aid the domain owner in tracking down the sender. Jesse ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] p=quarantine
> On 11 Dec 2020, at 17:07, Dave Crocker wrote: > > On 12/11/2020 8:32 AM, Kurt Andersen (b) wrote: >> Perhaps: >> none: not certain at all >> quarantine: I believe I've got control of all my sending, but am >> not 100% positive >> reject: I have control of all my sending; if it doesn't pass DMARC, >> it's use of the domain is bogus. >> >> But the problem case in our off-topic rabbit trail meanderings is that >> people who "have control of all their sending" still don't necessarily send >> mail of consistent seriousness nor do they have any control of the paths by >> which that mail takes to get to the ultimate recipient. There is a >> conflation of "control of emission" with "control of path". > > A specification providing a choice of labels/settings needs to have a shared > understanding of what those labels mean. > > It seems pretty clear that DMARC's p= hasn't had that, to date. There is no > consistency to the criteria used to set the label and, I suspect, little > consistency to how a receiver's filtering engine uses it. > > We need to settle on text that resonates with a consistent interpretation, by > both domain owners and email receivers. > > I've offered an approach that might permit reaching that community -- not > just IETF -- rough consensus. > > At this point we need to get suggested revisions for improvement. For now, I > don't have better text to suggest. > There’s probably better phrasing than ‘DMARC compliant’ here, but here’s my stab at describing the processes. note, this is very close to the language I use with clients. p=none: mail sent by authorized users of this domain may or may not be aligned in a DMARC compliant way. p=quarantine: mail sent by authorized users of this domain should be aligned in a DMARC compliant way. Mail that is unaligned may or may not be legitimate messages from this organization. p=reject: all mail sent from this domain should be aligned in a DMARC compliant way. Mail that is unaligned is not authorized by the domain owner and may be discarded or rejected by the recipient. laura -- Having an Email Crisis? We can help! 800 823-9674 Laura Atkins Word to the Wise la...@wordtothewise.com (650) 437-0741 Email Delivery Blog: https://wordtothewise.com/blog ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] p=quarantine
On 12/11/2020 8:32 AM, Kurt Andersen (b) wrote: Perhaps: none: not certain at all quarantine: I believe I've got control of all my sending, but am not 100% positive reject: I have control of all my sending; if it doesn't pass DMARC, it's use of the domain is bogus. But the problem case in our off-topic rabbit trail meanderings is that people who "have control of all their sending" still don't necessarily send mail of consistent seriousness nor do they have any control of the paths by which that mail takes to get to the ultimate recipient. There is a conflation of "control of emission" with "control of path". A specification providing a choice of labels/settings needs to have a shared understanding of what those labels mean. It seems pretty clear that DMARC's p= hasn't had that, to date. There is no consistency to the criteria used to set the label and, I suspect, little consistency to how a receiver's filtering engine uses it. We need to settle on text that resonates with a consistent interpretation, by both domain owners and email receivers. I've offered an approach that might permit reaching that community -- not just IETF -- rough consensus. At this point we need to get suggested revisions for improvement. For now, I don't have better text to suggest. d/ -- Dave Crocker dcroc...@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter American Red Cross dave.crock...@redcross.org ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] dmarc - New Meeting Session Request for IETF 110
Hi Kurt, Murray will correct me if I am wrong, but I have several comments: On Fri, Dec 11, 2020, at 12:37 AM, Kurt Andersen (b) wrote: > I'm wondering why we should wait for IETF110 rather than having an interim > meeting sooner. Interim meetings are also likely to garner greater > participation since they do not include participation fee. If there are > topics worthy of F2F discussion, why wait? If there are not, then why charge > people to join a pointless meeting? 1). All online IETFs this year had "free attendence" option. If people can afford to pay to attend, they should, as this supports RFC publication cost, cost of online meetings, etc. But people can attend for free if needs be. As far as I know this is going to be the case for IETF 110. 2). Chairs are considering interims and we will schedule them if/when needed. 3). Chairs will discuss around February 1st whether we think we can have a productive meeting at IETF 110. We can cancel if there are no reasons to have online meeting during IETF 110 week. Best Regards, Alexey > > --Kurt > > On Tue, Dec 8, 2020 at 10:25 AM IETF Meeting Session Request Tool > wrote: >> >> >> A new meeting session request has just been submitted by Alexey Melnikov, a >> Chair of the dmarc working group. >> >> >> - >> Working Group Name: Domain-based Message Authentication, Reporting >> Conformance >> Area Name: Applications and Real-Time Area >> Session Requester: Alexey Melnikov >> >> >> Number of Sessions: 1 >> Length of Session(s): 1 Hour >> Number of Attendees: 76 >> Conflicts to Avoid: >> Chair Conflict: dnsop dprive cfrg kitten emailcore >> Technology Overlap: saag uta extra jmap cbor >> >> >> >> >> >> >> People who must be present: >> Alexey Melnikov >> Murray Kucherawy >> Tim Wicinski >> Seth Blank >> >> Resources Requested: >> >> Special Requests: >> >> - >> >> >> ___ >> 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] p=quarantine
On Thu, Dec 10, 2020 at 6:26 PM Dave Crocker wrote: > On 12/10/2020 6:01 PM, Kurt Andersen (b) wrote: > > I think that is much closer to the right semantic but highlights a > > problem that the mail coming from a particular domain probably doesn't > > rate a single broad-brush characterization of seriousness. > > I've assumed the none, quarantine, reject choices are meant to indicate > just how certain the domain owner is that the mail is problematic. > > Perhaps: > > none: not certain at all > > quarantine: I believe I've got control of all my sending, but am > not 100% positive > > reject: I have control of all my sending; if it doesn't pass DMARC, > it's use of the domain is bogus. > But the problem case in our off-topic rabbit trail meanderings is that people who "have control of all their sending" still don't necessarily send mail of consistent seriousness nor do they have any control of the paths by which that mail takes to get to the ultimate recipient. There is a conflation of "control of emission" with "control of path". --Kurt ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] p=quarantine
On 12/11/2020 11:10 AM, Hector Santos wrote: * SPF -ALL, REJECT - Receiver rejects at MAIL FROM state with a 550 response. Correction: * SPF -ALL, REJECT - Receiver rejects at RCPT TO state with a 550 response. SPF is only tested once a valid (existing) RCPT TO is provided. This was the very first major optimization done with SPF back in 2003/2004 when it was first changed from MAIL FROM to RCPT TO. It resulted in a DNS lookup overhead savings of 60% because at the time, 60% of the RCPT TO were "unknown, not locally hosted" addresses. This mode of operation is on-par with the SMTP RFC5321 Section 3.3 recommendation: 3.3 Mail Transactions . Despite the apparent scope of this requirement, there are circumstances in which the acceptability of the reverse-path may not be determined until one or more forward-paths (in RCPT commands) can be examined. In those cases, the server MAY reasonably accept the reverse-path (with a 250 reply) and then report problems after the forward-paths are received and examined. Normally, failures produce 550 or 553 replies. -- Hector Santos, https://secure.santronics.com https://twitter.com/hectorsantos ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] p=quarantine
On Fri, Dec 11, 2020 at 11:11 AM Hector Santos wrote: > We are not doing reporting at this > time. Not the main focus. That can come later as an augmented > feature, in fact, we might consider it as a paid service to be sending > thousands report out to domains. > That's good community spirit. I doubt many would be willing to pay you for your reports. Michael Hammer ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] p=quarantine
On 12/10/2020 9:26 PM, Dave Crocker wrote: On 12/10/2020 6:01 PM, Kurt Andersen (b) wrote: I think that is much closer to the right semantic but highlights a problem that the mail coming from a particular domain probably doesn't rate a single broad-brush characterization of seriousness. I've assumed the none, quarantine, reject choices are meant to indicate just how certain the domain owner is that the mail is problematic. Perhaps: + none: not certain at all quarantine: I believe I've got control of all my sending, but am not 100% positive reject: I have control of all my sending; if it doesn't pass DMARC, it's use of the domain is bogus. When it comes to keeping focus with the purpose of SPF and DKIM-POLICY protocols and its implementation out of the box, default behavior: 1) The main purpose is Receiver Abuse Control. 2) Special attention to Port 25 Unsolicited Anonymous Senders and Message Authors. 3) For authenticated, authorized, white listed clients, SPF and DKIM do not apply, mail is always accepted. Hard policies with SPF and DKIM-POLICY are honored aggressively. Softer policies are processed, classified and passed through to next filters, if any remaining, i.e. GreyListing. * SPF -ALL, REJECT - Receiver rejects at MAIL FROM state with a 550 response. * ADSP DKIM=DISCARDABLE, Receiver rejects at SMTP DATA state with a negative 550 DATA response. * DMARC p=reject, Receiver rejects at SMTP DATA state with a negative 550 DATA response. * DMARC p=quarantine, Receiver accepts at SMTP. Mail is moved outside targeted users' main inbox mail stream, i.e. can not be picked up by user's POP3 or normal mail pickup process. The user has to login in online to see the mail in another non-inbox folder, i.e. spam box. Thats it. No reporting. Period. The domain should be grateful their public mail policy instructions is being honored for strict operations at compliant receivers. I hope their compliant receivers are also honoring our strict public mail policies as well to help protect fraudulent usage. I really do not need a report for the expected action when fraudulent mail is detected. Overall, the receiver is doing the domain a favor by helping them protect their domain reputation from possible fraudulent usage of their domains, and at the same time, it is helping its own system and the target hosted user from potential abuse as well -- a win win situation. For List-related situations, the receiver follows the 2006 DSAP recommendations: https://tools.ietf.org/html/draft-santos-dkim-dsap-00 1) If a new subscribing domain has a restrictive public mail policy with ADSP and/or DMARC, the subscription is denied. 2) Incoming messages are checked for mailing list destinations. If the submitter's domain have restrictive public mail policies with ADSP or DMARC, the submission is rejected with a 550. With these two simple peripheral filters, there was no need to modify the legacy list server source code for Rewriting or anything else related to the "in-direct" mail problem. The DMARCbis codification/changes I am looking for are: 1) Improvements in the DNS lookup algorithm, optional additional lookups should be provided or referenced. 2) Recognition and support for ATPS to cover 3rd party authorization. and other fine tunning, clarifications, for example, in another thread, it was stated: "When you switch to p=quarantine pct=0, no one should apply quarantine (so it's equivalent to p=none)," I thought the "pct=" was related to when reporting should be applied. I apparently read it wrong. This needs to be code reviewed and corrected on our end, if needed. We are not doing reporting at this time. Not the main focus. That can come later as an augmented feature, in fact, we might consider it as a paid service to be sending thousands report out to domains. Keep it simple folks. Be safe and have a great weekend. Thanks -- Hector Santos, https://secure.santronics.com https://twitter.com/hectorsantos ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Ticket #61 - Define and add a simplified (redacted) failure report
On Thu 10/Dec/2020 17:59:54 +0100 Jesse Thompson wrote: > On 12/9/20 10:28 PM, seth wrote: >> As an individual, I feel extremely strongly that failure reports should go >> away in their entirety. Although Jesse Thompson has outlined a use case that >> really has no other good solution, and is equally true in other large >> complicated organizations. > > To be clear, I'm not advocating for this From/To use case, but I know of > universities who would. There's at least one who cleverly flattened their > SPF record to include every known sender specifically because they had no > mission to change the way their institution distributively sends email. That > is the type of organization who *may* want From/To data, assuming they want > to do more validation before adding yet another IP to their SPF. It's a > stretch in my mind. I'm not clear whether you're talking about sending or receiving reports. Received: chains are key for evaluating addresses to add to SPF records. I don't think it makes sense to specify their omission from My guess at why an organization may want to send only From/To rather than a possibly redacted text/rfc822-headers are as follows: * It is too hard for them to asses the risk of including unknown header fields, yet they must do it before enabling ruf, * the software they use doesn't have an option to redact PII, or (unlikely) * they try to save bandwidth and disk space by reducing that ghastly pile of freaky fields that infest message headers these days. > I would only strongly advocate for seeing the unredacted From header, since > my primary concern was with identifying a little bit more information about > who was using the domain and why (i.e. who is using random ESP). Agreed. > The stated purpose of Failure Reports is "for quickly notifying the Domain > Owners when there is an authentication failure ... also provide more > information about the failed message than is available in an aggregate > report". Since the focus of DMARC is to authorize the use of the domain used > in the From header, then the logical next incremental levels of "more > information" should be: > > 1) From header domain (already known) > 2) local part of From address > 3) Friendly From > 4) Subject > 5) other parts of the message containing identifiable information > > 1->5 decreases in usefulness/relevancy to DMARC > 1->5 increases in unnecessary information disclosure The mail filter I do sends aggregate reports but not failure reports. Should I add it? I'm thinking I could frame it like so: * Have a global flag to enable or disable ruf's, which can be overridden on a per-domain basis. Default to disabled. * The flag can specify three confidentiality levels: - full message - header only - header only + redact. * Redacting the header would work as follows: 1. Collect recipients addresses in To:, Cc:, and envelope, 2. compute the rfc6590-redacted version of each address, 3. for all fields, replace any occurrence with the redacted version. * Reports are left in a user-configured directory, assuming that a user supplied script deals with them. Does that make sense? Should dmarc-failure-reporting include text with practical suggestions along those lines? Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
