Re: consensus call of RR prefix

It has been claimed that MTA software is generally configured to reject e-mail that comes from a domain that doesn't exist.  [...]

[...] 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. 

No.  He's making the assumption that if an "MX" lookup returns a non-empty resource record set, the SMTP Relay server infers that the domain name does exist.  And he's entirely correct.

There is important difference that should be made by implementors about dns error codes. [...]

The distinction between a "no such name" error and an empty resource record set isn't relevant to what he is discussing here.  The wildcard transforms the "no such name" error into a non-empty MX resource record set, just as Verisign's wildcards did for A resource record sets.

Actually to be more precise NODATA should be given if answer section is empty, [...]

Wrong.  RFC 2308 shows several response forms comprising complete answers with empty resource record sets, that do not have empty "answer" sections.  Not only is an empty "answer" section not the definition of an empty resource record set answer, it actually doesn't convey the empty resource record set properly (because of a schema mismatch between the DNS protocol and the DNS database).  It doesn't convey the TTL information for the empty resource record set.

but dns resolvers can't make this assumption because of other problems; 

They cannot make that assumption because it is a wrong one to make.

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...

Either way around is perfectly legitimate.  The well-known problem with some (broken) content DNS server softwares and AAAA resource record sets is that they'll answer with the data for an A query but give a "no such name" answer to an AAAA query, making the apparent existence of the name in IP6-aware applications dependent from the exact relative order in which the A and AAAA lookups are done.