On October 30, 2021 1:58:00 AM UTC, Douglas Foster <[email protected]> wrote: >I enthusiastically endorse John's proposal for policy discovery. But as >stated previously, I do not see that it provides a viable mechanism for >eliminating the PSL as an alignment tool. To address that part of the >problem, I submit my proposal for migrating from the publicsuffix.org list >to DNS flags. > >Doug Foster > >PSL replacement using DNS Flags > >This proposal specifies a resource record that can be used to distinguish >between PSL names and organization-controlled names. The design also >permits fine-tuning of organization-controlled names to obstruct misuse of >those names. > >When this mechanism is available, it provides sufficient information to the >evaluator so that the Public Suffix List from publicsuffix.org does not >need to be checked. In the future, if participation becomes sufficiently >widespread, evaluators may choose to bypass the publicsuffix.org list >completely. >Resource Record Definition (type=TXT) > >All interpretations apply to the Resource Record’s DNS name. No cascading >of information is used. > >Label: DMARCFLAGS > >Version tag v=1 > >Tokens: > >· SMTPFROM=FALSE >Name is never used for SMTP MailFrom addresses. Stronger repudiation than >SPF FAIL. Equivalent to “SPF -ALL”, primarily included here for simplified >PSL configuration. Applicable if no SPF policy exists. If an SPF policy >exists, the policy takes precedence. When omitted, the default >interpretation is TRUE, the name may be used for SMTP MailFrom. > >· MSGFROM=(TRUE | FALSE ) >When this token is not used, the default depends on SPF. If SPF is “-ALL” >or SMTPFROM=FALSE, the MSGFROM defaults to FALSE. If any other SPF record >exists, defaults to TRUE. If no SPF record exists, default is UNKNOWN. > >o MSGFROM=FALSE >Name is never used for message FROM header address. Stronger repudiation >than DMARC FAIL. > >o MSGFROM=TRUE >Name may be used for message FROM header address. Primarily used to >ensure that From non-existence tests recognize that the name exists and is >valid for Email FROM addresses. > >· DKIM=FALSE >Stronger than DKIM verification failure. If name cannot be verified >because a public key is not found in DNS, treat the signature as a fake. >When not present, TRUE is assumed. > >· ALIGN=FALSE >Name is not usable for alignment of non-matching domain names. Primarily >used to indicate a PSL entry. When not present, TRUE is presumed. >Specifying ALIGN=FALSE implies that all parent domains are also >characterized by ALIGN=FALSE. To avoid inconsistent results, it should >only be published when parent domains have also published ALIGN=FALSE. >Use Cases PSL Name > >A PSL name is not usable for mail or for alignment, so the record has these >values: > >“DMARCFLAGS v=1 SMTPFROM=FALSE MSGFFROM=FALSE DKIM=FALSE ALIGN=FALSE” >Organization-owned Mail Server > >An organization-owned mail-sending server uses its own domain for both the >SMTP MailFrom and the message From header, and is also likely to use the >domain name to sign messages. So all defaults are applicable and the >MSGFROM clause is optional as long as an SPF record is present. To be >explicit, this record would be used. > >“DMARCFLAGS v=1 MSGFROM=TRUE” >Organization subdomain used only for Mailing Service messages > >Mailing services typical use one of their own subdomains for the SMTP >MailFrom address, to ensure SPF PASS. The client organization chooses the >message From address from the domain tree that it controls. If a From >address subdomain name is only used in this context, it may have no other >existence in DNS, without this clause, it might be considered >non-existent. This record documents the use of the name for the message >FROM header while repudiating its use for SMTP MailFrom. > >“DMARCFLAGS v=1 SMTPFROM=FALSE MSGFROM=TRUE” >Mailing service SMTP names used for client messages > >Mailing services typically use their own subdomain names for the SMTP >MailFrom address, to ensure SPF PASS. These subdomain names are typically >used only in this context, never for sending the service provider’s own >mail. The subdomain may or may not be used for DKIM signatures, so these >records are possible. > >“DMARCFLAGS v=1 MSGFROM=FALSE” >or >“DMARCFLAGS v=1 MSGFROM=FALSE DKIM=FALSE” >Holding Company with Isolation between Subsidiaries > >This is an unlikely situation, but is supported by the design. Assume that >Example.Com is a large conglomerate with subsidiaries involved in >activities as wide-ranging as oil exploration and home repair. >Example.Com does not want to allow subsidiaries to send on each other’s >behalf, so it does not want the corporate parent domain to be used for >alignment. Corporate messages will be sent using exact-match alignment, >while subsidiary companies will use normal alignment up to the subsidiary’s >parent domain. This record documents the holding company policy: > >“DMARCFLAGS v=1 ALIGN=FALSE” >Domain or Subdomain which is never used for sending email > >If a name is not used for either SMTP MailFrom or message FROM header, then >the name can be strongly protected against misuse with this record: > >“DMARCFLAGS v=1 SMTPFROM=FALSE MSGFROM=FALSE DKIM=FALSE”
None of that is needed for DMARC. Also, if you want to communicate a domain name is never used in Mail From, you can already publish v=spf1 -all. The absence of a published selector does the same for DKIM. Why don't you focus in on the problem you are trying to solve before you jump to a specific solution, because I can't tell what it is? Scott K _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
