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”
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
