On Wed, 8 Sep 2004, Mark Lentczner wrote:
The use of the wildcard with -all is an attempt to catch all e-mail
which someone might send with forged malicious intermediate names:
joe(_at_)random-host(_dot_)example(_dot_)com
It has been claimed that MTA software is generally configured to reject
e-mail that comes from a domain that doesn't exist. While this is true
at my site, I have seen no stats to back the claim up. Unless the
numbers were very high (>95%), I'm not sure relying on other people's
MTAs to catch this for one's domain is a good idea.
Nonetheless, many sites have wildcard MX records so that they can catch
mail sent to any address. This means that they want to receive mail,
not matter how it is addressed within their domain, but they don't
authorize sending with such addresses. In theses cases, all domains
exist (due to the wildcard MX record), and so other people's MTAs won't
reject based on domain non-existance.
You're making an assumption that to check if domain exist one would make
an "A" or "AAAA" query on that domain and if no record is received assume
that domain is invalid, that is not correct.
There is important difference that should be made by implementors about
dns error codes. If domain does not exist the correct error code is RCODE3
(NXDOMAIN) and in that case you can safely assume there is no such domain
and reject the email.
However if subdomain is defined by wildcard MX record (or any other wildcard
record for that matter), the query for "A" on that domain would return
RCODE 0 (NO ERROR), but there would not be an an ip address available for
query in the ANSWER section, which would cause normal dns resolver to
answer with its own error code (NODATA for bind-based resolver).
(Actually to be more precise NODATA should be given if answer section is
empty, but dns resolvers can't make this assumption because of other
problems; for example if direct name does not exist but there is a CNAME
or DNAME record for the same name, the answer section given by dns
server should contain that - unfortunetly I sometimes see CNAMEs listed
in Additional section. At the same time query for A when there is an AAAA
on some servers would cause an AAAA to be addded to additional section,
or possible that is the other way around...)
P.S. I recently wrote my own dns resolver, so these things had to be
looked up in RFCs and sometimes found just by direct testing. Also
I'm of the opinion that DNS RFCs are inconsistant with some of the
existing implementations (bind, djbdns, etc), the responses are
different for example between various versions of bind if domain is
not deligated (and when its deligated authoritive NS servers appear in
different sections depending on bind dns server version). Its still
amazes me that dns works so well with so much difference in responses;
the credit goes to dns resolvers, that try to account for all these
differences and always use Postel's principal to be very liberal in what
you accept.
--
William Leibzon
Elan Networks
william(_at_)elan(_dot_)net