|
Re: [ietf-dkim] 2821bis and AAAA (was: Thoughts on latest SSP draft)
2007-09-27 12:18:30
On Sep 27, 2007, at 1:38 AM, Frank Ellermann wrote:
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.
Increasing levels of spam is requiring receivers to add resources.
Additional transactions for random domains will amplify the need for
additional resources.
In addition to checking for a policy record of some sort, A, AAAA,
and MX records must also be queried. Every message referencing a
randomly spoofed domain will thereby lead to a series of expensive
DNS transactions. DNS overhead could be reduced by 2/3 thirds at
least by requiring an MX record for acceptance. This would preclude
A or AAAA record for acceptance. The impact of this change should be
limited to message acceptance.
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.
Attempting to also connect to an SMTP server would also require
receivers to increase resources. To limit the impact of this
increase, specialized caching would be needed. Unlike DNS, each SMTP
connection requires TCP setup. Many of the inbound systems are
overloaded with spam, where without retries, a failure to connect
will reduce email's delivery integrity. In addition, inbound
connections should be held during this process.
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.
The goal would be to limit spoofing. This requires every address
record to have an adjacent policy record that indicates this address
record is not used for email. Policy records of every sort would
need to be published adjacent to each address record. Cluttering
zones with email policy records is sub-optimal. This problem is best
resolved by requiring MX records.
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.
Currently checking for MX, A, and AAAA records would be required to
avoid tree walking.
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."
At least. It would be nice to obtain enough consensus that would
allow use of A records to hereby be deprecated. I suspect this must
be done in a separate draft, or by de-facto behaviour.
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.
That would still demand an inordinate level of policy records.
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.
I agree.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
|
|