ietf-mxcomp
[Top] [All Lists]

Re: consensus call of RR prefix

2004-09-08 17:45:49


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