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] draft-crocker-dmarc-author-00 ?
On 8/13/20 4:53 PM, dotz...@gmail.com wrote: > Wrong answer. If the vendor is uncooperative then fire the vendor. 4-5 years > ago it was difficult to find vendors who were willing to deal with DKIM and > able to do a good job in implementing. The common mantra was "how does this > fit into my business model". These days I would consider it table stakes. DKIM, DMARC policy conformance, or any practical email functionality are rarely considered in procurement decisions. Only recently did I manage to get some of these requirements into our organization's RFP templates. It really hasn't made any impact on procurement decisions, which are made by people who don't understand the nuances of email to the extend that they can tell if the vendor actually meets the requirements. Even if I were included on the evaluation team for every procurement (a job I do not want) it would be rare that lack of DKIM support would be enough to weigh negatively on a decision. People like me only get called in after the system is deployed in production and they run into problems getting email delivered. For one recently-procured (inventory management software) vendor, I had to coach a poor sysadmin through how to set up Postfix to relay-rewrite their own application's email so that it wasn't able to outright spoof (for lack of a better term) the address of any end-user-free-hand-inputted address. Their own app dev team didn't feel like it was important enough to learn about DKIM/SPF/DMARC and kept confusing the changes they needed to make for email authentication with TLS 1.0 deprecation. "It's in our next release" they kept saying. Companies like that will just check the "we support DMARC" on the procurement form because they don't know enough to understand that they don't. 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] non-mailing list use case for differing header domains
On 8/18/20 3:54 AM, Alessandro Vesely wrote: > On Tue 18/Aug/2020 01:39:16 +0200 Jesse Thompson wrote: >> On 8/7/20 9:32 PM, John Levine wrote: We need spoofing protection for all of our domains without being told we're misdeploying. >>> >>> I would be interested to better undertstand the meaning of "need" >>> here. It is my impression that most people vastly overestimate how >>> much of a phish target they are. Paypal and big banks certainly are, >>> other places, a lot less so. >> >> (Sorry, I was on a much-needed vacation.) > > > Much *needed*? Oh, well... Anecdotally. My family can attest, if that helps ;-) >> Ok, that's fair, I should have realized that one was over-stated. *Need* >> would imply that domain-spoofing is more common than it is in reality. > > > Yes, domain spoofing is common. You don't need to be PayPal to be spoofed. > Then, one can say it's an innocuous kind of abuse. Since you're not PayPal, > it's just noise. Yet, in a perfect word, I'd opt to avoid it. Yes, I just can't prove it to the extent that the people saying we're "misdeploying" DMARC would expect me to. How do I tell the difference between a faculty member innocently using Gmail to send from their personal address within our domain vs. a bad actor doing the same to send spear phishing to a peer at another university? In my mind, I should just assume that it's a problem, or is potentially a problem, so I'd rather nip it in the bud by deploying DMARC on domains used by users. >> Cybersecurity-minded folk in EDU tend to equate observed inbound phishing >> with spoofing (even though most phishing is spoofing the display name and >> message bodies, not the domain) and conclude that they *need* DMARC without >> really understanding the nuances. Given the opportunity that DMARC >> marketing promises, they definitely *want* inbound DMARC enforcement for >> domain-spoofing of inbound mail (they'll defer to the email-minded folk to >> figure out the local policy exemptions, ARC, etc), as well as *want* domain >> policies that prevent the potential domain spoofing scenarios of owned >> domains (again, the email-minded folk will figure out how to actually >> "misdeploy" DMARC). To them, it's just a checkmark towards some "maturity" >> benchmark that they use to compare to their peers. > > > Nice synthesis. They believe DMARC works as advertised. What does it take > to believe that DMARC /could/ work as advertised? It seems like we're close. I am glad that you are pushing back (in the other thread) on the notion that DMARC shouldn't be useful for all types of domains. >> Email-minded folk in EDU, knowing that DMARC doesn't really have much >> practical application to phishing, like having the observability that DMARC >> provides, as well as the hammer that moving past p=none provides as a way to >> coerce their complex, decentralized institution into a more sustainable >> operation: >> >> * 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) > > > This is a good idea even without DMARC concerns. Yes, and those departments that we have converted to subdomains seem to be happy with the result. It usually takes some convincing, however. People tend to have a strong preference to associate with the brand of the org domain (which is where we have our users). >> * People sending user email from random places - move them to authenticated >> submission (preferably OAuth - since basic authentication is the reason why >> so many passwords are exposed) > > > This sound just like an email-client configuration problem. It shouldn't be > so hard. Gmail is the most common "client" allowing users to submit mail outside of our supported submission pathways. In theory, Google could make some improvements to Gmailify (to support more OAuth scenarios) and actively transition their legacy users to reconfigure their Gmail settings to properly use our domain, but it's not a high priority for Google (paraphrasing Brandon; hopefully accurately) It's not much different than people innocently using any random ESP to send newsletters from their personal address. Because all of these "clients" allow non-authenticated submission of our domain, users have come to expect it to work and they don't want to be told otherwise. >> The latter scenario is interesting because a single user sending from a >> random place doesn't really show up in DMARC aggregate reports. > > > Why not? If they send to DMARC-compliant receivers, their aggregate reports > should show records without the right MSA signature, not even failed, and > foreign domain authentications only. That doesn't tell which users > misconfigured their client, but gives a good idea of the level of user > education one has achieved. Right, you onl
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
On Tue, Aug 18, 2020 at 6:49 AM Douglas E. Foster wrote: > 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 > Not as a 3rd party, but we were doing ad-hoc signing for a large number of domains (hundreds) at our outbound border MTAs at scale -10s of millions of messages an hour, with the ability to scale much much larger for holiday peaks. This was done with both Ironport and MessgeSystems implementations. It's literally a very little bit of logic and code. As long as you have the private keys it's as simple as choosing the path to the correct signing key based on having the From domain. This was at various points done in Python and Lua. Michael Hammer ___ 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
Re: [dmarc-ietf] non-mailing list use case for differing header domains
I have seen Jesse mention something along these lines a couple of times: * 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. Thanks, Autumn Tyr-Salvia atyrsal...@agari.com Agari Principal Customer Success Engineer From: dmarc on behalf of Jesse Thompson Sent: Monday, August 17, 2020 4:39 PM To: John Levine ; dmarc@ietf.org Subject: Re: [dmarc-ietf] non-mailing list use case for differing header domains On 8/7/20 9:32 PM, John Levine wrote: >> We need spoofing protection for all of our domains without being told we're >> misdeploying. > > I would be interested to better undertstand the meaning of "need" > here. It is my impression that most people vastly overestimate how > much of a phish target they are. Paypal and big banks certainly are, > other places, a lot less so. (Sorry, I was on a much-needed vacation.) Ok, that's fair, I should have realized that one was over-stated. *Need* would imply that domain-spoofing is more common than it is in reality. Cybersecurity-minded folk in EDU tend to equate observed inbound phishing with spoofing (even though most phishing is spoofing the display name and message bodies, not the domain) and conclude that they *need* DMARC without really understanding the nuances. Given the opportunity that DMARC marketing promises, they definitely *want* inbound DMARC enforcement for domain-spoofing of inbound mail (they'll defer to the email-minded folk to figure out the local policy exemptions, ARC, etc), as well as *want* domain policies that prevent the potential domain spoofing scenarios of owned domains (again, the email-minded folk will figure out how to actually "misdeploy" DMARC).. To them, it's just a checkmark towards some "maturity" benchmark that they use to compare to their peers. Email-minded folk in EDU, knowing that DMARC doesn't really have much practical application to phishing, like having the observability that DMARC provides, as well as the hammer that moving past p=none provides as a way to coerce their complex, decentralized institution into a more sustainable operation: * 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) * People sending user email from random places - move them to authenticated submission (preferably OAuth - since basic authentication is the reason why so many passwords are exposed) The latter scenario is interesting because a single user sending from a random place doesn't really show up in DMARC aggregate reports. It may show up in forensic reports, but it is easily lost in the noise. (SPF macros might be another way to get fine-grained observability, but that's a privacy leakage IMO.) In the end, it still results in: * That person wouldn't end up on our radar for communication * That person wouldn't understand what the message is about, even if we did communicate with them * That person wouldn't comply, even if they understood * Once enforcement is in place, that person will complain and leverage every ounce of their political influence to resist. (It's really fun when your own users threaten lawsuits against you - that doesn't happen in Corporate IT.) I'm kind of rambling now, I see. Hope you find it enlightening, regardless! Jesse ___ dmarc mailing list dmarc@ietf.org https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fdmarc&data=02%7C01%7Catyrsalvia%40agari.com%7C07fe631db10e49cfa46508d84306d0b9%7C05773123385e420d844ef01aee5e37ab%7C0%7C0%7C637333043846011888&sdata=GEKpu8y3KvA7Zkt0VJmeKz4KPwvSay51cj5SDniQAUo%3D&reserved=0 ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] non-mailing list use case for differing header domains
On Tue 18/Aug/2020 01:39:16 +0200 Jesse Thompson wrote: > On 8/7/20 9:32 PM, John Levine wrote: >>> We need spoofing protection for all of our domains without being told we're >>> misdeploying. >> >> I would be interested to better undertstand the meaning of "need" >> here. It is my impression that most people vastly overestimate how >> much of a phish target they are. Paypal and big banks certainly are, >> other places, a lot less so. > > (Sorry, I was on a much-needed vacation.) Much *needed*? Oh, well... > Ok, that's fair, I should have realized that one was over-stated. *Need* > would imply that domain-spoofing is more common than it is in reality. Yes, domain spoofing is common. You don't need to be PayPal to be spoofed. Then, one can say it's an innocuous kind of abuse. Since you're not PayPal, it's just noise. Yet, in a perfect word, I'd opt to avoid it. > Cybersecurity-minded folk in EDU tend to equate observed inbound phishing > with spoofing (even though most phishing is spoofing the display name and > message bodies, not the domain) and conclude that they *need* DMARC without > really understanding the nuances. Given the opportunity that DMARC marketing > promises, they definitely *want* inbound DMARC enforcement for > domain-spoofing of inbound mail (they'll defer to the email-minded folk to > figure out the local policy exemptions, ARC, etc), as well as *want* domain > policies that prevent the potential domain spoofing scenarios of owned > domains (again, the email-minded folk will figure out how to actually > "misdeploy" DMARC). To them, it's just a checkmark towards some "maturity" > benchmark that they use to compare to their peers. Nice synthesis. They believe DMARC works as advertised. What does it take to believe that DMARC /could/ work as advertised? > Email-minded folk in EDU, knowing that DMARC doesn't really have much > practical application to phishing, like having the observability that DMARC > provides, as well as the hammer that moving past p=none provides as a way to > coerce their complex, decentralized institution into a more sustainable > operation: > > * 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) This is a good idea even without DMARC concerns. > * People sending user email from random places - move them to authenticated > submission (preferably OAuth - since basic authentication is the reason why > so many passwords are exposed) This sound just like an email-client configuration problem. It shouldn't be so hard. > The latter scenario is interesting because a single user sending from a > random place doesn't really show up in DMARC aggregate reports. Why not? If they send to DMARC-compliant receivers, their aggregate reports should show records without the right MSA signature, not even failed, and foreign domain authentications only. That doesn't tell which users misconfigured their client, but gives a good idea of the level of user education one has achieved. It should also show which domains users tend to use for submission, in case an organization wants to automate third-party authorization... Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
