[Mimedefang] Domain canonifyin?g and RFCs

[Joseph Brennan]

> [False] If set, $[ ... $] lookups that do DNS based lookups do not
> expand CNAME records. This currently violates the published standards,
> but the IETF seems to be moving toward legalizing this. For example,
> if "FTP.Foo.ORG" is a CNAME for "Cruft.Foo.ORG", then with this option
> set a lookup of "FTP" will return "FTP.Foo.ORG"; if clear it returns
> "Cruft.FOO.ORG". N.B. you may not see any effect until your downstream
> neighbors stop doing CNAME lookups as well.


DontExpandCnames was introduced in 8.7, September 1995, well before
RFC 2821 (2001). The release note is similar:--

        Add DontExpandCnames option to prevent $[ ... $] from expanding 
CNAMEs
                when running DNS.  For example, if the name FTP.Foo.ORG is
                a CNAME for Cruft.Foo.ORG, then when sitting on a machine in
	        the Foo.ORG domain a lookup of "FTP" returns "Cruft.Foo.ORG"
	        if this option is not set, or "FTP.Foo.ORG" if it is set.
                This is technically illegal under RFC 822 and 1123, but the
                IETF is moving toward legalizing it.  Note that turning on
                this option is not sufficient to guarantee that a downstream
	        neighbor won't rewrite the address for you.

The way it's written there, it seems to be about converting bare hostnames
in my local domain into FQDNs. Should "FTP" become "FTP.Foo.ORG" (a CNAME)
or "Cruft.Foo.ORG".

But in the domain.c source file, whether you constructed a possible FQDN
by appending the local domain, or had a FQDN to start with, if it's a
CNAME and DontExpandCnames is true, it stops there, and otherwise it
goes on to do the rewrite we're familiar with.


Check this though- section 5 of RFC 2821:--

                             The lookup first attempts to locate an MX
   record associated with the name.  If a CNAME record is found instead,
   the resulting name is processed as if it were the initial name.  If
   no MX records are found, but an A RR is found, the A RR is treated as
   if it was associated with an implicit MX RR, with a preference of 0,
   pointing to that host.

So prefer MX, and if there is no MX, an A record is an implicit MX. OK,
we all know this.

But if a CNAME is found "instead"-- and this seems to imply, as RFC 1034
also implies, that you can't have both CNAME and MX together-- then the
"resulting name" is processed. What's the "resulting name"? The result
of canonifying the CNAME to an A record?

Similar in RFC 5321 section 5.1, without "instead":--

   The lookup first attempts to locate an MX record associated with the
   name.  If a CNAME record is found, the resulting name is processed as
   if it were the initial name.

Both say that in the absence of an MX record, an A record is an implicit
MX record, but both do *not* say that a CNAME can be an implicit MX. So
we have a logical problem:

(a) If there is a CNAME, there can't be an MX record.

(b) If there is no MX record, a CNAME is not an implicit MX record.

So where would mail go?



And... I need to go back to my real work :-)

Joseph Brennan
Columbia University Information Technology