On Friday, October 29, 2021 7:06:18 AM EDT Douglas Foster wrote: > PSL entries are imputed with four important characteristics: > - name not valid for MAILFROM > - name not valid for FROM > - name not valid for DKIM > - name not valid as an alignment point for mismatched names. > > For non-PSL names, the reverse is assumed by default - any name is valid > for any of these purposes. > > It is important to note that the PSL covers all possible names -- if a name > prefix is not in the PSL, we assume it is a fake name. Experience also > indicates that it is trusted as accurate. We have not spent any time > talking about a need for PSL override rules. > > Finding the first available DMARC policy, as John suggests, does not come > close to replacing the PSL. > > - First, DMARC policies do not cover all possible names, which is a > rather critical problem. > > - Secondly, even when they are present, the first-match DMARC policy does > not define all valid alignment points. Consider unit2.example.com and > unit1.example.com. Each unit may have its own DMARC policy, but the > parent domain may still be a valid alignment point. > > I can test alignment without a DMARC policy, but I cannot test alignment > without a PSL or a comparable replacement. We could define DNS flags to > cover the four PSL characteristics listed above, and those flags have > potential use cases outside of the PSL But we have already concluded that > we cannot reliably expect every PSL to configure DNS entries to meet our > needs, so the DNS-based PSL would lack the necessary trust that we have in > the current PSL.
Have you looked at the PSL? I mean the actual content? In the public names section of the PSL, here are the entries with three or more dots: schools.nsw.edu.au pvt.k12.ma.us chtr.k12.ma.us paroch.k12.ma.us I think it was a mistake for RFC 7489 not to specify that the private domains section of the PSL shouldn't be used. Using the private ones doesn't change the equation much, but I don't think these merit any special consideration. It does get you one more dot. Here's the four dot private names: *.compute.amazonaws.com.cn cn-north-1.eb.amazonaws.com.cn cn-northwest-1.eb.amazonaws.com.cn *.elb.amazonaws.com.cn s3.cn-north-1.amazonaws.com.cn s3.dualstack.ap-northeast-1.amazonaws.com s3.dualstack.ap-northeast-2.amazonaws.com s3.dualstack.ap-south-1.amazonaws.com s3.dualstack.ap-southeast-1.amazonaws.com s3.dualstack.ap-southeast-2.amazonaws.com s3.dualstack.ca-central-1.amazonaws.com s3.dualstack.eu-central-1.amazonaws.com s3.dualstack.eu-west-1.amazonaws.com s3.dualstack.eu-west-2.amazonaws.com s3.dualstack.eu-west-3.amazonaws.com s3.dualstack.sa-east-1.amazonaws.com s3.dualstack.us-east-1.amazonaws.com s3.dualstack.us-east-2.amazonaws.com app.os.stg.fedoraproject.org users.scale.virtualcloud.com.br it1.eur.aruba.jenv-aruba.cloud cloud.jelastic.open.tim.it If you include the private names, the organizational domain for example.s3.dualstack.ap-northeast-1.amazonaws.com is example.s3.dualstack.ap- northeast-1.amazonaws.com, not amazonaws.com (RFC 7489 3.2 Step 3 specifies the longest match). That can't be what we would want. As John has suggested, DNS is pretty flat and there are solutions for fakes that are deep in the tree that don't need the PSL. If paroch.k12.ma.us were to publish a DMARC record that caused a problem for a parochial school in the US state of Massachusetts, then I think it's fair to say that the school should take that up with the operator of paroch.k12.ma.us. It's enough of a corner case that it's not worth giving up the benefit of not being dependent on the PSL. Keep in mind, even if you're assessment were correct and we agreed it's important, it would only describe the PSL as it exists today with an assumption it's accurate. If you look in the comments of the PSL it's clear that it is incomplete, known to be incomplete by the PSL maintainers, and will remain that way. Even if we liked the idea of email being dependent on an external list, it's not clear that the PSL is really a complete enough answer to that question. It got DMARC out the door to start, but let's not pretend it's more than it is. Scott K _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
