Douglas Otis wrote: > Email policy solutions assume policy can be asserted for parent > domains and all sub-domains.
Not for SPF, and it took me some time to figure this out in 2004: A receiver getting mail with an alleged evelope sender [EMAIL PROTECTED] can reject it as soon as it's clear that there's no MX, no A, and no AAAA for y.example. Zone cuts, DNS tree walks, or SPF aren't needed for this decision. Email policy solutions like SPF don't need to worry about "impossible" sub-domains, the receicers are anyway obliged to reject mail from an "impossible" [EMAIL PROTECTED] at least temporarily, otherwise they couldn't report later errors. In theory they could accept it if they're sure that there will be no problem with final delivery, and that triggered auto responses going to /dev/null are no issue, but that's already deep in the territory of "receiver policies". Sender policies can focus on domains with an MX, plus A or AAAA cases for domains without MX. They don't need to cover complete subtrees. If the MX or A / AAAA is a wildcard the corresponding policy also needs to be a wildcard. > a policy record needs to be published at every existing node For some definitions of "existing" by "has MX, A, or AAAA", yes. OTOH receivers could check that the A / AAAA without MX cases have an SMTP listening on port 25, and otherwise decide that an alleged envelope sender address isn't acceptable for the purpose of sending later error reports to the originator "as indicated by the reverse path", the keystone of SMTP. This check might be simpler than trying to find and interprete sender policies, and the A / AAAA without MX cases should be rare. > Publishing a policy record adjacent every existing node will > be difficult to manage. It depends on what you want. If you never use any @www.example address in email, and there's no MX for or SMTP at www.example, you could decide that's good enough. An admin for bank.example likely decides that www.bank.example has to be covered. > Walking even a small portion of the label tree might negatively > impact SLD and TLDs. Yes, tree walks are odd when they cross zone cuts, that's not limited to TLDs and SLDs like ac.uk. >> AFAIK it's not planned to remove the "A fallback" from 2821bis, >> in fact 2821bis will augment all discussions of A records with >> AAAA for IPv6 compatibility. > AAAA record discovery could be excluded in 2821bis and require > the use of MX records. Okay, for that section 2.3.5 at the moment offers: | Only resolvable, fully-qualified, domain names (FQDNs) are | permitted when domain names are used in SMTP. In other words, | names that can be resolved to MX RRs or address (i.e. A or | AAAA) RRs (as discussed in Section 5) are permitted, as are | CNAME RRs whose targets can be resolved, in turn, to MX or | address RRs. For your proposal it should say ..."MX RRs or IPv4 addresses (i.e. A) are permitted"..."resolved, in turn, to MX or IPv4 address RRs." And the details in section 5 would have to fixed, limiting the "no-MX" procedure to the legacy IPv4 case, plus something about IPv4 addresses as they're seen in an IPv6 environment. > At some point, even A records for discovery should be > deprecated. I'm pretty sure that the 2821bis author would insist on saying that this point isn't *now*. But for IPv6 (and any IPvFuture) there might be enough wiggle room. Frank _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
