On Thu, Aug 13, 2020 at 6:53 PM Neil Anuskiewicz <n...@marmot-tech.com> wrote:
> > > On Thu, Aug 13, 2020 at 2:33 PM Doug Foster <fosterd= > 40bayviewphysicians....@dmarc.ietf.org> wrote: > >> If I followed Neil’s discussion of MajorCRM: >> >> >> >> The current DMARC architecture supports authorizing a vendor to mail on >> behalf of their clients if the client includes them in their SPF policy or >> delegates a DKIM scope to them and they use it. >> > > And client's domain is only in the Mail from uses the vendor's domain ( > somevendorxyz123.foo.com). It passes SPF in but it's not in alignment > with the organizational domain name (example.com) that the client uses in > the header from. > > This is super common and, as a practical matter, it works... except if you > ever want to use DMARC's policy for anything other than reporting. The vast > majority of people think that if you add include:bar.com (whatever vendor > KB says) in the SPF that they are good to go. > "Vast majority of people"? Can you please provide data that supports this assertion? > So many businesses have several entries in their organizational domain's > SPF record yet the RFC5321.from is the vendor's domain. The client > sometimes goes over the 10 DNS lookups with includes that aren't doing > anything for them. I'm not sure that 10 DNS lookup limit. There are some > prominent services of various sorts for which the single include will do > over 10 DNS lookups and hat's just one of many includes a client might have > (I know this isn't about SPF per se). > > Yes, I can usually quickly set up a subdomain to use instead of > somevendorxyz123.foo.com but this isn't always possible or it requires > pushing to get it done. > So you are saying "Email authentication is hard. Let's go shopping"? > > This makes DMARC a sketchy tool to use for any policy above none which is > in and of itself useful. > Not at all. It simply means that the people/organizations involved have some problems. Please consider the following joke: How many Psychiatrists does it take to change a light bulb? Only one but the bulb has to want to change. I've been involved in setting up DMARC with a policy of p=reject for somewhere North of 6,000 domains. As a sending domain, the heavy lifting is in getting buy-in across the organization that it is a worthwhile effort, getting control of your organization's mail flows and ensuring policies and procedures are communicated and followed. For complex environments there may need to be some automation required for creating and maintaining private/public key pairs and DNS records but that is much more straightforward than the aforementioned heavy lifting. Michael Hammer. > >
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
