Re: [dmarc-ietf] Revisiting the Race Condition in draft-crocker-dmarc-sender-01
In article you write: >This is just wrong. While I appreciate the enthusiasm for using the Sender >field, unless there is a mechanism for establishing a relationship between >the From domain and the Sender domain then we have basically broken DMARC. >Using what has been described above, any malicious actor can bypass the >wishes of the From domain and send whatever they want. Aw, come on. Surely you of all people know that DMARC aligned doesn't mean it's not spam. the whole reason we're here is that we have abundant evidence that at least where mailing lists are involved, the policy published in DMARC often doesn't express the actual wishes of the domain publishing it. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Revisiting the Race Condition in draft-crocker-dmarc-sender-01
On Tuesday, August 18, 2020, Dave Crocker wrote: > On 8/18/2020 12:48 PM, Todd Herr wrote: > >> The race condition here is in item 5, "Emails that fail the DMARC >> mechanism check are disposed of in accordance with the discovered DMARC >> policy of the Domain Owner", specifically when both the Sender and From >> headers are present, the domains are different, both publish DMARC >> policies, and only one of the two domains passes DMARC validation checks >> for that message. In that case, the question of "Which policy to apply?", >> or more precisely, "Which validation check should be honored?" will really >> matter to the disposition of the message; if, for example, the From domain >> is at p=reject and fails, while the Sender domain publishes a policy with >> the required "snd" tag and passes, should the message be rejected or >> accepted? >> > > > So, yeah, the text for that needs significant changes. Thanks for raising > this. > > I was under some time pressure and merely copied that from the existing > DMARC spec. In fact, I think that text in the DMARC spec isn't very good, > so this would be a nice excuse for thinking through reasonable language > carefully. > > The basic issue, which creates the language challenge, is the receivers > actually can and do do whatever they want. Language that pretends to > dictate receiver action for this is unrealistic. > > So the language should be cast in terms of the semantics of the > information it is tossing into the receiver's analysis engine, rather than > claiming to dictate receiver disposition of the message. IMO. > > d/ > > -- > Dave Crocker > Brandenburg InternetWorking > bbiw.net > > This is just wrong. While I appreciate the enthusiasm for using the Sender field, unless there is a mechanism for establishing a relationship between the From domain and the Sender domain then we have basically broken DMARC. Using what has been described above, any malicious actor can bypass the wishes of the From domain and send whatever they want. I fail to see how this would be considered a feature. It is precisely why I proposed a separate signature of the Sender field by the From domain to at least provide a way to show a relationship between the Two domains. There currently is no race condition because Sender is not currently a part of DMARC. It appears that people want to introduce the same problem that existed in SenderID and PRA. Please don't. Michael Hammer ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Revisiting the Race Condition in draft-crocker-dmarc-sender-01
On 8/18/2020 12:48 PM, Todd Herr wrote: The race condition here is in item 5, "Emails that fail the DMARC mechanism check are disposed of in accordance with the discovered DMARC policy of the Domain Owner", specifically when both the Sender and From headers are present, the domains are different, both publish DMARC policies, and only one of the two domains passes DMARC validation checks for that message. In that case, the question of "Which policy to apply?", or more precisely, "Which validation check should be honored?" will really matter to the disposition of the message; if, for example, the From domain is at p=reject and fails, while the Sender domain publishes a policy with the required "snd" tag and passes, should the message be rejected or accepted? So, yeah, the text for that needs significant changes. Thanks for raising this. I was under some time pressure and merely copied that from the existing DMARC spec. In fact, I think that text in the DMARC spec isn't very good, so this would be a nice excuse for thinking through reasonable language carefully. The basic issue, which creates the language challenge, is the receivers actually can and do do whatever they want. Language that pretends to dictate receiver action for this is unrealistic. So the language should be cast in terms of the semantics of the information it is tossing into the receiver's analysis engine, rather than claiming to dictate receiver disposition of the message. IMO. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Revisiting the Race Condition in draft-crocker-dmarc-sender-01
In article you write: >[What to do when From and Sender DMARC have different results ?] > >When I first posed this, the answers I got were along the lines of >"Receivers will do what they want, like they've always done", and that's >certainly true if the behavior isn't mandated in the RFC (and maybe even if >it is). That's cool and all, but doesn't "Receiver's Choice" risk >continued, or perhaps even worse, breakage of the primary problem that this >document is trying to fix? You're right, the sender tweak only makes sense if the sender result is preferred. Otherwise a sender result can only make it less likely that a message is delivered, and that wouldn't be very useful. As always, a successful result doesn't mean not spam, it just means it didn't fail DMARC. I expect some non-normative advice would be helpful, pointing out that this is useful for third party senders, and recipient systems will have to come up with their own idea about which third parties are credible. It occurs to me it's likely to be the same list of third parties whose ARC seals are credible. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
[dmarc-ietf] Revisiting the Race Condition in draft-crocker-dmarc-sender-01
Greetings. I want to revisit something that was originally discussed in the "non-mailing list use case for differing header domains" thread, because I don't think there was any sort of consensus reached, and because I think it's pretty important in determining whether or not the proposed document will achieve any level of successful adoption. If this topic was discussed in a different thread, please forgive me for beating what I'm sure must be a dead horse. Section 5.2, Determine Handling Policy, reads in part: The steps are as follows: 1. Sender: Extract the RFC5322.Sender domain from the message. Query the DNS for a DMARC policy record. Perform remaining, numbered steps, if one is found and it contains an "snd" tag. AND From: Extract the RFC5322.From domain from the message. Query the DNS for a DMARC policy record Perform remaining, numbered steps, if one is found. Terminate: Otherwise terminate DMARC evaluation. 2. Perform DKIM signature verification checks. A single email could contain multiple DKIM signatures. The results of this step are passed to the remainder of the algorithm and MUST include the value of the "d=" tag from each checked DKIM signature. Crocker Expires January 28, 2021[Page 6]Internet-DraftDMARCJuly 2020 3. Perform SPF validation checks. The results of this step are passed to the remainder of the algorithm and MUST include the domain name used to complete the SPF check. 4. Conduct Identifier Alignment checks. With authentication checks and policy discovery performed, the Mail Receiver checks to see if Authenticated Identifiers fall into alignment. If one or more of the Authenticated Identifiers align with the RFC5322.From (or with the RFC5322.Sender field, if permitted by the domain owner) domain, the message is considered to pass the DMARC mechanism check. All other conditions (authentication failures, identifier mismatches) are considered to be DMARC mechanism check failures. 5. Apply policy. Emails that fail the DMARC mechanism check are disposed of in accordance with the discovered DMARC policy of the Domain Owner. See Section 6.3 for details. The race condition here is in item 5, "Emails that fail the DMARC mechanism check are disposed of in accordance with the discovered DMARC policy of the Domain Owner", specifically when both the Sender and From headers are present, the domains are different, both publish DMARC policies, and only one of the two domains passes DMARC validation checks for that message. In that case, the question of "Which policy to apply?", or more precisely, "Which validation check should be honored?" will really matter to the disposition of the message; if, for example, the From domain is at p=reject and fails, while the Sender domain publishes a policy with the required "snd" tag and passes, should the message be rejected or accepted? When I first posed this, the answers I got were along the lines of "Receivers will do what they want, like they've always done", and that's certainly true if the behavior isn't mandated in the RFC (and maybe even if it is). That's cool and all, but doesn't "Receiver's Choice" risk continued, or perhaps even worse, breakage of the primary problem that this document is trying to fix? Unless I'm misunderstanding things, a primary idea behind the Sender header with the DMARC policy is to make things easier for intermediaries, like this mailing list. I'm posting to this list from a domain that publishes a p=reject policy, and so to allow my post to make it to all subscribers, the MLM rewrites the From address something that looks kind of VERP-ish (todd.herr=40valimail@dmarc.ietf.org), DKIM signs it using the ietf.org domain, and sends it along with a MAIL FROM domain ending in ietf.org. If this change becomes standard, then I imagine that future mail sent through this MLM will look something like this: From: todd.h...@valimail.com Sender: l...@dmarc.ietf.org DKIM-Signature domain (d=ietf.org) Return-Path domain: ietf.org There may still be a DKIM signature header with d=valimail.com attached to the message, but DMARC for valimail.com won't validate because of the footer attached to the message, and so we'll be in a situation at best where the Sender DMARC check passes and the From DMARC check fails, with the From domain being at p=reject. What if the receiver bounces the message because of this failure of DMARC validation on the From field? We're playing "Receiver's Choice" here, so there's nothing to stop them from doing so, right? If the spec doesn't mandate behavior in cases where there are conflicting DMARC validation results, then it doesn't seem to achieve the goal it set out to accomplish: If: *
Re: [dmarc-ietf] draft-crocker-dmarc-author-00 ?
On 8/17/20 3:00 PM, Luis E. Muñoz wrote: > DMARC can be quite useful even with p=none. Agreed. People commonly request that we accept-list their IP/domain from inbound spam scanning. We now tell them to send DMARC-aligned mail (SPF or DKIM pass, aligned with From), and we'll use that as criteria to accept mail from the domain, regardless of what policy they actually publish. Jesse ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Time for a change
On Mon, Aug 17, 2020 at 6:09 PM Dave Crocker wrote: > DKIM was a synthesis within the IETF of two things (DomainKeys and IIM) > that started outside. It underwent significant evolution in the IETF -- > not once, but twice. > > Actually, it wasn't. > > The constituent parts were separately proposed, during the same initial > IETF discussions, and the IETF said to go away and come back after > reconciliation. That work was done by an ad hoc industry team and there > was a complete spec and initial implementations before the IETF was again > approached. > Yep, I still have the t-shirt. > https://tools.ietf.org/html/draft-allman-dkim-base-00 > > (and note that in the working group field on the title page, it says > "pre-MASS"...) > > The work in the IETF was a refinement of a complete, integrated spec. > But it was quite a bit of refinement -- I would even say 'evolution" -- in comparison to how little SPF and DMARC changed before publication. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] draft-crocker-dmarc-author-00 ?
On Mon, Aug 17, 2020 at 1:00 PM Luis E. Muñoz wrote: > On 14 Aug 2020, at 12:47, Neil Anuskiewicz wrote: > > Under 50% of companies have any DMARC record. Of those who deploy > > DMARC, > > about ~2% have p=quarantine and ~5% p=reject, though some industries > > such > > as finance it looks like it's closer to 15% p=reject. I'm sure these > > numbers aren't perfect but what you have likely isn't radically > > different. > > My numbers are inverted regarding quarantine vs reject, as I posted on > this list: > > On 30 Jul 2020, at 18:01, Luis E. Muñoz wrote: > > > > I am currently observing ~215.5 million domain names. Out of those, > > ~64 million have a seemingly _valid_ SPF record and ~113 million with > > at least one MX record. > > > > This is a current breakdown of the (valid) DMARC records I am > > observing over the general domain population above. This amounts to an > > adoption rate of ~1.7%. > > > > |p | count | > > | :- | --: | > > | none | 2715614 | > > | quarantine | 238584 | > > | reject | 726045 | > > Numbers have moved a bit since then, but not much. I'm seeing 3:1 reject > to quarantine ratio across the board. > > > Why is adoption low? Is that a big problem? Why so few aggressive > > policies? > > Is that a big problem? > > DMARC can be quite useful even with p=none. This use case provides > insight on what's going on and sometimes, that's all that is wanted. > Moving to more aggressive policies require a degree of control on the > mail flows that not all organizations are prepared to exercise, IMO. > > Yes, I completely agree, p=none is useful. It's helped me help the client (I'm basically an IT freelancer) make sure all their email sources' DKIM and SPF's squared away. More interesting, DMARC's found things that have surprised clients. Wait, who's using ESP X? Some detective work and a few days later... Okay, it's the such and such office or sometimes even individuals. And there's oh right we do use Y. Let's get that authenticated.. So it's legit sources that need to be authenticated, semi-legit sources that either need to be authenticated and viewed as fully legit or told to stop and there's sources that are legit but have been running on autopilot. Let's think about whether we need this or what changes we can make to it. This aspect serves as a sort of internal audit of email sources and authentication. DMARC's been very, very useful for that. Then there's discovering spoofing sometimes, of course. Neil ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] finer grained org domain
There is a ticket for tree walk: https://trac.ietf.org/trac/dmarc/ticket/68 Please hold the conversation until the chairs open that thread. Seth, as Chair On Tue, Aug 18, 2020 at 9:49 AM Dave Crocker wrote: > On 8/18/2020 9:43 AM, Tim Wicinski wrote: > > I do think the tree walk deserves another look. Years back when it was > brought up, > there was lots of talk of overloading resolvers. But as someone who spent > the past > several years looking at the DNS query data of good sized SaaS domains, > DMARC lookups > (or even DMARC NXDOMAINs) were on the low end of the spectrum. Nowadays, > all web > properties point to CDNs, et al with 30 second TTLs. > > To be entirely obvious: > > badactor.a.b.c.d.e.f.g.h.i.j.k.l.m.n.o.p.yougetheidea.example.com > > produces a possible denial of service attack. hence, no tree-walking. > > d/ > > -- > Dave Crocker > Brandenburg InternetWorkingbbiw.net > > ___ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > -- *Seth Blank* | VP, Standards and New Technologies *e:* s...@valimail.com *p:* 415.273.8818 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] finer grained org domain
On 8/18/2020 9:43 AM, Tim Wicinski wrote: I do think the tree walk deserves another look. Years back when it was brought up, there was lots of talk of overloading resolvers. But as someone who spent the past several years looking at the DNS query data of good sized SaaS domains, DMARC lookups (or even DMARC NXDOMAINs) were on the low end of the spectrum. Nowadays, all web properties point to CDNs, et al with 30 second TTLs. To be entirely obvious: badactor.a.b.c.d.e.f.g.h.i.j.k.l.m.n.o.p.yougetheidea.example.com produces a possible denial of service attack. hence, no tree-walking. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] finer grained org domain
On 8/18/2020 9:39 AM, John R Levine wrote: We've spun our wheels a lot trying to figure out a better way to find the organizational domain than for everyone to download the Mozilla PSL, but not about changing it to a tree walk. If we could come up with a better way for domains to publish their own boundaries (see https://github.com/jrlevine/bound) then that would be easy. And for completeness: DNS Perimeter Overlay https://tools.ietf.org/id/draft-dcrocker-dns-perimeter-01.html (John thinks it's the same as his, but it's not...) d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] finer grained org domain
Speaking not as a chair... I do think the tree walk deserves another look. Years back when it was brought up, there was lots of talk of overloading resolvers. But as someone who spent the past several years looking at the DNS query data of good sized SaaS domains, DMARC lookups (or even DMARC NXDOMAINs) were on the low end of the spectrum. Nowadays, all web properties point to CDNs, et al with 30 second TTLs. tim On Tue, Aug 18, 2020 at 12:39 PM John R Levine wrote: > On Tue, 18 Aug 2020, Autumn Tyr-Salvia wrote: > > * Departments sending transactional email - move them to dedicated > subdomains (this is where really complex institutions would benefit from > walking the domain tree instead of always inheriting from the org domain) > > > > Is inheritance walking the domain tree a topic that has already been > discussed ad nauseam? This seems like an interesting point of discussion, > but I also haven't been participating on this list for ten years and don't > want to get into it if this is a topic everyone is tired of or that has no > possibility of change. > > We've spun our wheels a lot trying to figure out a better way to find the > organizational domain than for everyone to download the Mozilla PSL, but > not about changing it to a tree walk. > > If we could come up with a better way for domains to publish their own > boundaries (see https://github.com/jrlevine/bound) then that would be > easy. > > 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 > ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] finer grained org domain
On Tue, 18 Aug 2020, Autumn Tyr-Salvia wrote: * Departments sending transactional email - move them to dedicated subdomains (this is where really complex institutions would benefit from walking the domain tree instead of always inheriting from the org domain) Is inheritance walking the domain tree a topic that has already been discussed ad nauseam? This seems like an interesting point of discussion, but I also haven't been participating on this list for ten years and don't want to get into it if this is a topic everyone is tired of or that has no possibility of change. We've spun our wheels a lot trying to figure out a better way to find the organizational domain than for everyone to download the Mozilla PSL, but not about changing it to a tree walk. If we could come up with a better way for domains to publish their own boundaries (see https://github.com/jrlevine/bound) then that would be easy. 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] DMARC failure scenarios
You cannot make sense of it, John. I understand the difference between submssion and SMTP. The asserted increase in complexity is not from adding a single signature, it is the requirement to apply a different signature to every message depending on the generated From domain. Are applications like the one the Alessandro mentioned readily available and easily implemented, so that conditional signatures are no hindrance to DMARC compliance? If so, is third-party cooperation easily achieved and no obstacle to DMARC implementation? These are questions for the consultants who have done a lot of this work. DF From: "John Levine" Sent: 8/17/20 10:12 PM To: dmarc@ietf.org Cc: fost...@bayviewphysicians.com Subject: Re: [dmarc-ietf] DMARC failure scenarios In article <0762f9ada48c4c9eaef06e16a49a2...@bayviewphysicians.com> you write: >-=-=-=-=-=- > >Does this scenario correctly characterize how organizations may be unable to >move past p=none with breaking things? As far as I can made sense of it, no. >a) A vendor application detects an event, looks up in a database for sender >name (client contact) and recipient list. > >b) The application connects to a mail server via IMAP, and sends the message >using something like application@vendordomain >for the SMTP from and cllentcontact@clientdomain as the Message from. The >client domain becomes especially important if >the recipients are in a different domain than the client. An example might be >an HVAC system operated by a vendor, on >behalf of the building manager, which needs to communicate with the building >tenants. ... Again, no. You're confusing submission with SMTP. I have a printer that sends me e-mail when it's out of paper, which it does by sending mail to my submission server, not directly to me. If I were checking DMARC on the messages, they would easily pass since the submission server adds DKIM signatures. >Then the client wants to implement DMARC >-- > >d) The client develops a list of all of its third-party mailers and tells the >third parties to begin applying the client's >DKIM signature to their messages. This adds a boatload of complexity to the >vendor's application, since he needs a >different applied signature for each client. It requires either major changes >to the application, a more sophisticated >mail server, or a special box simply to sit in front of the mail server to >detect and apply the correct signature. None of >these seem like generic off-the-shelf solutions. I would not know where to buy >that capability if I needed it today. Again, no. I believe that devices that send mail do what they've always done, send it to a submission server for further delivery. The "special box" has been there all along. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC failure scenarios
On Tue 18/Aug/2020 03:56:12 +0200 Douglas E. Foster wrote: d) The client develops a list of all of its third-party mailers and tells the third parties to begin applying the client's DKIM signature to their messages. This adds a boatload of complexity to the vendor's application, since he needs a different applied signature for each client. It requires either major changes to the application, a more sophisticated mail server, or a special box simply to sit in front of the mail server to detect and apply the correct signature. None of these seem like generic off-the-shelf solutions. I would not know where to buy that capability if I needed it today. It doesn't have to add much complexity. My DKIM filter[*] looks up the signing domain in a configured folder where it can find the selector and the private key —actually a symbolic link. The signing domain can be configured to be the domain of the From: field. The app just has to use the client's domain for both the envelop and the header, which is actually simpler than the pre-DMARC case. The client must publish the public key supplied by the vendor and include the vendor's SPF stuff in its record. That's not automated, AFAIK, although dynamic DNS and suitable scripts could do. Best Ale -- [*] http://www.tana.it/sw/zdkimfilter/zdkimfilter.html#signing ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
