ietf-smtp
[Top] [All Lists]

Re: Registration model, 2821bis-06

2008-04-03 16:24:46
On 2008-04-02 08:31:34 -0400, Keith Moore wrote:



Arnt Gulbrandsen wrote:

How many people would be happy if 5.1 were to say this?

- if there is no MX record, but there is an A, then the sending
  host MUST synthesise an MX
- if there is no MX record and no A, but there is an AAAA, then
  the sending host MAY synthesise an MX
- even if a client doesn't use AAAA records for synthesising MX
  records, it MAY use them for delivering mail once an MX has
  been synthesised.

first rule is fine - really I think that fallback to A should eventually 
be deprecated (probably as of some flag day) but 2821bis clearly is not 
the place to do this.

second rule - MAY should be SHOULD NOT, perhaps even MUST NOT.

third rule is a bad idea, IMHO.

I don't even understand what the third rule means. If an MX record isn't
synthesized in the first place how can it be used to look up an AAAA
record? Or does that mean that it is ok for a client to use an AAAA
record only if there is also an A record? If so, I agree that's a bad
idea.


the 974 fallback means that no MX 
records + an A record implies authorization to deliver mail to that IPv4 
address.  it doesn't imply any authorization to deliver mail to any IPv6 
address.

I think the 974 fallback does imply exactly that. It says so
explicitely:

|  Where ever
|  delivering a message is mentioned, all that is meant is that the
|  mailer should do whatever it needs to do to transfer a message to a
|  remote site, given a domain name for that site.  (For example, an
|  SMTP mailer will try to get an address for the domain name, which
|  involves another query to the domain system, and then, if it gets an
|  address, connect to the SMTP TCP port).

"whatever it needs to do ... given a domain name" and "an address for
the domain name" means to me "lookup both A and AAAA records" in a mixed
IPv4/IPv6 world.

It is also implicit in the order:

1) Do an MX lookup, which results in an ordered list of (priority,
   hostname) tuples..

2) If the list is empty, insert (0, REMOTE)

3) Remove unusable hostnames from the list.

4) "try to deliver" (as defined above) to the hosts in order.

Note that steps 1 to 3 do not involve any A records. Only step 4
involves lookup of an address record, because you need an IP address to
open a TCP connection.


So far this is IMO very clear and unambiguous.


RFC 2821 changed that, by changing step 2 above (which doesn't mention
or need an A record into:

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

The requirement "but an A RR is found" is new here. I don't know why it
was added and whether the change was intentional: If there is only IPv4,
the change makes no difference at all - maybe it was only meant as a
clarification, not a change. But with IPv6 there is a change. Firstly,
the RFC restricts the use of generic "address records" to specific "A
records", so it forbids the use if IPv6 (this probably wasn't
intentional, since the use of IPv6 address literals is explicitely
allowed, which wouldn't make much sense in an IPv4-only protocol).
Secondly, it uses A records in two places: For address resolution and
for determining whether the implicit MX record should be synthesized at
all (in RFC 974 it was always synthesized, regardless of the presence or
absence of an address (or any other non-MX) record). So now we have two
places where we have to decide whether we extend "A record" to "any
address record". Clearly we need to lookup AAAA records to determine the
address of an IPv6 host, so that's beyond question. But we don't
necessarily need to lookup an AAAA reccord to synthesize an MX record.
However, looking up only an A record here leads to my nonsensical
interpretation of rule 3. 

I understand the desire to get rid of the fallback. However, I don't
think that the wording in RFC 2821 can be reasonably extended to
"fallback for IPv4 only". To get useful behaviour it would need to
changed significantly, and that would be a direct contradiction to RFC
974 which should be explicitely mentioned and explained. Just going back
to the simple rules of 974 (which draft-klensin-rfc2821bis-09
essentially does, although I find the description in RFC 974 clearer) is
IMHO the only way under the constraints of going from proposed to draft
standard. If the fallback goes for AAAA records, I would very much like
to see it deprecated for A records, too (something like "clients MUST
lookup an A record, but SMTP service operators SHOULD NOT rely on this
behaviour and SHOULD add an explicit MX record").

        hp


-- 
   _  | Peter J. Holzer    | It took a genius to create [TeX],
|_|_) | Sysadmin WSR       | and it takes a genius to maintain it.
| |   | hjp(_at_)hjp(_dot_)at         | That's not engineering, that's art.
__/   | http://www.hjp.at/ |    -- David Kastrup in comp.text.tex

Attachment: signature.asc
Description: Digital signature

<Prev in Thread] Current Thread [Next in Thread>