Re: [dmarc-ietf] 5.7.2.1. DMARC Policy Discovery - How to handle a missing policy
On Tue, Jan 4, 2022 at 4:53 PM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > [...] > The PASS-centric approach is the only one that makes sense to me. This is > why I have lobbied for changes to the introduction to explicitly state that > FAIL is an ambiguous result. If you accept that PASS-centric is the goal, > then using default policies becomes the necessary way of coping with > missing information. > I would argue that it's well understood by now that DKIM and SPF "pass" results are the only things that convey usable information. You know something about a message that passes; when they fail, the algorithm itself can't tell you what the exact nature of the failure is. Section 6.3 of RFC 6376 spends some time discussing this. I think in DMARC, a strong policy is a tacit expression that the domain posting that policy understands the narrow but meaningful nature of the "pass" cases of those protocols, and only wants participating receivers to deliver messages within that definition. But if we believe that's not implicit or made clear by the document as-is, or if the industry at large has missed this point, then sure, we could say so here. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Section 5 - DKIM-only authentication
Like everyone else, receivers will do what they perceive as their own self interest. The goal of a document like this is to a lay out a plan where everyone can pursue their own self interest in a way that benefits the group. In this case, the "group" is senders of wanted mail and the receivers who want that mail. Senders who want to use a DKIM-only strategy for DMARC should consider how that strategy will be received by evaluators who do not implement DMARC. Based on the implementations that I have observed, I would expect such participants to only use SPF FAIL for rejecting suspected impersonation and absence of MX/A to reject messages from suspected fake names. But based on your experience, some of them require an SPF record also. The sender can ensure DKIM-only for DMARC by causing any SPF result other than PASS. FAIL and SOFTFAIL should be avoided, leaving NONE, NEUTRAL, and PERMFAIL as options. I have suggested that they should publish "?ALL" to ensure a result of NEUTRAL, since this will ensure that DMARC cannot be SPF aligned, while also ensuring that Best-Guess SPF will not be used in response to NONE. In your experience, what do these SPF-mandatory evaluators consider to be an acceptable SPF policy and policy result? Do you think "?ALL" would have qualified? Doug Foster On Tue, Jan 4, 2022 at 9:42 AM Tobias Herkula wrote: > One big thing missing in the Discussion are Receiver obligations, I > encountered a lof of Mailbox Providers that demand a valid and concise SPF > record, and in this case the Sender has no way to state that he requires > DKIM signatures for DMARC, the often stated argument of simply not > publishing SPF records if a Sender wants DKIM-only DMARC is not a viable > solution in the real world. > > > > / Tobias > > > > *Von:* dmarc *Im Auftrag von *Ken O'Driscoll > *Gesendet:* Dienstag, 4. Januar 2022 15:34 > *An:* Douglas Foster > *Cc:* IETF DMARC WG > *Betreff:* Re: [dmarc-ietf] Section 5 - DKIM-only authentication > > > > > > Organisations using DKIM-only (also SFP-only) with an enforcing DMARC > policy are more common than you may think. While some configurations are > perhaps in error, many I have encountered are deliberate decisions based on > specific use cases. > > > > For example, I have a finance house that uses DKIM-only auth with p=reject > on their main domain. When deploying DMARC they risked it and decided that > giving a third-party control of their SPF (via an include) was not an > option. It’s a valid reason whether one personally agrees with it or not. > There are tons of other reasons why organisations make similar decisions. > > > > Single auth is actively used in the wild. > > > > Ken. > > > > *From:* dmarc *On Behalf Of *Douglas Foster > *Sent:* Monday 27 December 2021 13:51 > *To:* IETF DMARC WG > *Subject:* [dmarc-ietf] Section 5 - DKIM-only authentication > > > > These two sections assume that some domain owners will want DMARC > authentication to be based on DKIM only. > > > > 5 Policy > > A Domain Owner can also choose to not have some underlying authentication > technologies apply to DMARC evaluation of its domain(s). In this case, the > Domain Owner simply declines to advertise participation in those schemes. > For example, if the results of path authorization checks ought not be > considered as part of the overall DMARC result for a given Author Domain, > then the Domain Owner does not publish an SPF policy record that can > produce an SPF pass result. > > > > 5.7.2. Determine Handling Policy > > Heuristics applied in the absence of use by a Domain Owner of either SPF > or DKIM (e.g., [Best-Guess-SPF]) SHOULD NOT be used, as it may be the case > that the Domain Owner wishes a Message Receiver not to consider the results > of that underlying authentication protocol at all. > > > > We agreed to drop the reference to Best-Guess-SPF, but we have not > addressed the underlying requirement. Do we actually have domain owners > who do not want SPF included in the DMARC evaluation process? If so, why? > > > > I am guessing that this request could only originate from a domain owner > with a valid but overly inclusive SPF record, probably because of include > clauses. The suggested strategy of no SPF record, or the equivalent > "?ALL", or not acceptable. These approaches only make a weak SPF policy > even weaker.To allow an overly-broad SPF policy to be ignored for DMARC > purposes, we should provide an explicit policy flag for this purpose. > > > > But each new option adds complexity. Is this option actually valuable to > somebody? > ___ > 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] Section 5 - DKIM-only authentication
On 1/5/2022 5:59 AM, Tobias Herkula wrote: I have one bigger example back from the days when I was working for an ESP. You've described a company making a set of operational decisions that are known to create problems when using DMARC. They also choose an ESP that imposes an operational requirement known to cause deliverability problems. And you somehow want to modify DMARC to 'fix' this? This is reminiscent of the explanation I got from a CEO, about the complaints sales folk were making about an excellent product, claiming that it needed this or that change: It saves them from doing their job of actually selling the existing product. The company needs to use the technology that exists, in a way that works, and to choose vendors that do the same. If they can find a serious constituency of other companies wanting similar changes, then maybe there is a task for DMARC to embrace. But only maybe. d/ -- Dave Crocker dcroc...@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter Information & Planning Coordinator American Red Cross dave.crock...@redcross.org ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Section 5 - DKIM-only authentication
On Wed, Jan 5, 2022 at 11:33 AM John R Levine wrote: > > I have one bigger example back from the days when I was working for an > > ESP. The Situation was that a financial Institution decided to sign all > > their messages with DKIM and deploy a DMARC reject policy and an active > > decision against a strict SPF record. Because a huge part of their > > Emails where constantly forwarded by their customer base and that > > created a lot of FP DMARC reports. At the same time a lot of their > > customers used a Mailboxprovider that required strict SPF records for > > Bulkmailersender. ... > > I believe it, but we all know why those are not smart things to do if you > want people to get they mail they want to receive. We could make all > sorts of changes to DMARC, and operators will continue to do foolish > things that loses their users' mail. So I do not want to waste time on > it. > > R's, > John > > PS: How do you say "you can't fix stupid" in German? > > I have to strongly agree with John on this. From an operational > perspective I believe Sending domains SHOULD get control of their outbound > mail, subdomains, etc. It is a one time cost but involves reworking > business processes, not just technical issues. Mailbox providers will make > local policy decisions regardless of IETF standards. There was a Polish > mailbox provider that would reject inbound mail if the MailFrom and From > address did not match exactly. I think it is a foolish choice but it is > their choice to make. We should be focusing on interoperability and NOT > local policy choices. Anything along the lines of local policy issues and > choices are best left to a BCP to be taken up at a later point if at all. > Michael Hammer ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Section 5 - DKIM-only authentication
I have one bigger example back from the days when I was working for an ESP. The Situation was that a financial Institution decided to sign all their messages with DKIM and deploy a DMARC reject policy and an active decision against a strict SPF record. Because a huge part of their Emails where constantly forwarded by their customer base and that created a lot of FP DMARC reports. At the same time a lot of their customers used a Mailboxprovider that required strict SPF records for Bulkmailersender. ... I believe it, but we all know why those are not smart things to do if you want people to get they mail they want to receive. We could make all sorts of changes to DMARC, and operators will continue to do foolish things that loses their users' mail. So I do not want to waste time on it. R's, John PS: How do you say "you can't fix stupid" in German? ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Section 5 - DKIM-only authentication
Hi John, I have one bigger example back from the days when I was working for an ESP. The Situation was that a financial Institution decided to sign all their messages with DKIM and deploy a DMARC reject policy and an active decision against a strict SPF record. Because a huge part of their Emails where constantly forwarded by their customer base and that created a lot of FP DMARC reports. At the same time a lot of their customers used a Mailboxprovider that required strict SPF records for Bulkmailersender. This dilemma wasn't solvable back then and isn't solvable now. As SPF is a global decision that needs to be made in comparison to DKIM where it is applied individually for each Email send Splitting that up into multiple Domains or Subdomains is not a viable alternative regarding Brand recognition, if my main goal is to reduce phishing attacks to my userbase. And I'm pretty sure that there are lot of people on this list here that are aware of Mailboxproviders who are very strict on requirements for Bulkmailsender, and it would be much easier to comply with these requirements if DMARC would allow to specify that a valid DKIM Signature is needed to pass the DMARC check, so that a SPF policy can be omitted to prevent forwarding problems or can be published to honor MBP requirements without increasing the perceived Risk of loose SPF-RR... / Tobias -Ursprüngliche Nachricht- Von: John Levine Gesendet: Dienstag, 4. Januar 2022 23:54 An: dmarc@ietf.org Cc: Tobias Herkula Betreff: Re: [dmarc-ietf] Section 5 - DKIM-only authentication It appears that Tobias Herkula said: >the often stated argument of simply not publishing SPF records if a >Sender wants DKIM-only DMARC is not a viable solution in the real world. If your SPF record accurately describes the sources of your mail, can you explain why it would be a problem for that to validate DMARC? The obvious problem would be "my mail provider is so incompetent that they let other people send phishes with my address" but that is definitely not a problem for anyone else to solve. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
