ietf-mxcomp
[Top] [All Lists]

Re: Wildcards

2004-05-19 11:44:47

Greg Connor <gconnor(_at_)nekodojo(_dot_)org> wrote:

... we have a few factors to deal with -- we probably don't need to
get into discussing the details of these but we should be aware of them.
(In other words, I'm not saying wildcards are a hard/fast requirement,
I'm just saying I don't want to take them off the table *yet*)

   I'd go a little farther -- still not claiming a "requirement", but
I believe wildcards _will_ be used and cannot be avoided.

1. If no MX exists, mailers fall back to A. So if www.example.com is a
web server, there's no easy way to tell if 
mail(_at_)www(_dot_)example(_dot_)com is valid.

   An excellent issue.

   Typically, there _will_ be some arrangement to accept email to
zzz(_at_)www(_dot_)example(_dot_)com; but it is done in many different ways, 
specifically
including wildcard MX.

   I won't say there's no satisfactory alternative to generating wildcard
records in order to accurately show policy, but I haven't though of any
entirely satisfactory one.

   In my "40% solution" I specified walking up the tree because I doubted
that domain managers would give us accurate records -- not because I
thought it was the right solution. I've since realized that we _can't_
call a bounce address "valid" if there is no MX, A or SRV record to lead
us to an IP address of a (potential) MTA. My bad.

   However, I'm not sure there's a workable alternative to trusting the
domain managers to guide their users into using addresses that work; and
the harm done by "validating" a bounce address which doesn't work really
isn't too serious...

   (Dave Crocker's Bounce Address Tag Verification seems likely to be
a solution to that problem, but I need a lot more details before trusting
it completely.)

2. The "inheritance" of marid records is not clear.  If there is no
record for www.example.com, we might want to fall back to example.com...
but if there is no record for demon.co.uk we would NOT want to fall back
to co.uk.

   Quite true. We might even come up with a list of "top-enough-level"
domains where we should stop progressing up the tree but it's clear we
can't specify that point for all future top-level-domains that may
happen. However, IMHO it's reasonable to expect registration services to
ensure that the registration level either contains no records that could
confuse us or contain records saying "No email here".

Figuring out where a subdomain splits into different ownership is not 
trivial.  The only way to be 100% accurate is to lookup the domain in 
question ONLY and not walk up the tree. 

   I'm not sure "100% accurate" is a plausible goal.

(We may decide that some level of inheritance is desired but we should
do so very carefully... 

   Agreed.

Not crossing an SOA boundary might be a good compromise)

   Disagree. I can see _very_ good reasons to have zone files within
a spread of domains under a single management; and I don't believe we
can hope for zone files in each case of management change.

   We _do_ need to be very clear about the conditions under which we
will walk up the tree; and I believe we'll have to trust DNS managers
to fix the problems which may ensue. (Keep in mind, though, that bounces
that fail are only a nuisance, not a problem; so we don't need a perfect
solution for RFC2821 MAIL FROM.)

3. Any site that has a wildcard A record or wildcard MX record MAY want
a wildcard LMAP record as well. 

   Absolutely!

Even if inheritance is sorted out, they may want the policy to be
different for *.example.com and example.com.

   Yes!

--
John Leslie <john(_at_)jlc(_dot_)net>


<Prev in Thread] Current Thread [Next in Thread>