ietf-smtp
[Top] [All Lists]

Re: Minor is. It's not a pardigm change

2008-04-05 11:55:00


On Sat, 2008-04-05, John C Klensin wrote:

If I correctly understand what you are suggesting, it is that,
if I have

   foo.example.com.  IN A #.#....
                     IN AAAA #:#:...

My SMTP client should somehow generate, not the implicit MX
called for by 2821bis (and 2821), which is

   foo.example.com.  IN MX 0 foo.example.com.

but some sort of MX arrangement that points to the A RR only and
not to the AAAA RR.   There is just no way to do that, at least
without putting completely new language in 2821bis that
distinguishes between the interpretation rules for implicit and
explicit MX records (and getting hopelessly entangled with and
overriding RFC 3484).

It seems to me that the above concept of "implicit MX" requires an extra
step that is not dictated by RFC 2821. In this concept the implicit MX is
automatically synthesized when no explicit MX was found. Then "address
records" would be looked up under that name (foo.example.com. above).

Extracting the important sentence from 2821, section 5:

   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.

My reading of this is: when an MX RR is not found then look for a an A RR
with the same name. If the A RR is found, *treat it as* though it was the
result of previously having found an MX pointing to that host name. Thus
there is no need for a subsequent lookup of both A and AAAA RRs.

What this says to me is that if we only look up A RRs in this step, there
will be only A RRs on hand to be returned as the resolution. If instead, we
look up both A RRs and AAAA RRs in order to determine if an implicit MX
should be used, there will be both types of address on hand to be returned.

I conclude that it *is* meaningful to allow only A RRs to be treated as
fallback MXs since the extra step of looking up address records at the
implicit MX target name is not actually required.

-- 
Bill McQuillan <McQuilWP(_at_)pobox(_dot_)com>