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 x(_at_)y(_dot_)example
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" x(_at_)y(_dot_)example 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