Date: Sat, 30 Jan 1999 12:58:05 -0500 (Eastern Standard Time)
From: John C Klensin <klensin@mci.net>
Subject: stripped-down client configuration (Address, MX RRs, A RR-only?)
To: drums@cs.utk.edu
Message-id: <SIMEON.9901301205.C@muahost.mci.net>
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Priority: NORMAL

Open question...

When one has a stripped-down SMTP client (e.g., one associated
with a POP3 or IMAP client), that client is usually configured
to forward mail to a "real" SMTP server for relaying.  There are
three theories about how that configuration should be done and
interpreted by the client (I've seen all three at one time or
another):

(i) Client configuration should use an IP address

  Pro: no ambiguity about what host is being referenced, saves
     DNS lookup time.
  Con: coded-in IP addresses, even in config files, are a bad
     idea, especially with IPv6 coming.  Addresses reduce
	 flexibility. 

(ii) Client configuration should use a domain name, which should
then be processed through MX resolution, etc.

  Pro: very flexible behavior, consistent with what real SMTP
     servers do, flexibility should be under the control of the
	 server operator.  Used by at least some ISPs to provide
	 alternate relays when some are busy.
  Con: Lower performance, client should be able to control
     everything, regardless of preferences of server operators
	 and zone admins.

(iii) Client configuration should use a domain name, but it
     should be interpreted as a reference to an A RR, i.e., no
	 MX resolution.

  Pro: More control by client, higher performance than MX
     resolution, reduction in risk of loops from badly
	 configured list of MX hosts.
  Con: A bit abnormal relative to how we handle mail; some names
     of interest may not have A RRs or the MX RR may point to
	 places besides the host associated with the A RR.

Of course, the first can be combined with either the second or
third. 


Observation #1: if an IMAP or POP3 client (probably the most
common cases of clients that need to be configured this way) is
queuing up mail and then sending multiple messages to the relay
in a single SMTP session (as currently suggested in 1123 and
821bis), the overheads here are per-session, rather than
per-message, and may not be significant on a per-message basis
(or at all).

Observation #2: Regardless of what decision is taken by DRUMS on
this subject, "dumb host can't support MX resolution" should not
be an excuse: such hosts are already non-standard and
non-conforming, per RFC 1123 and elsewhere.  Internet hosts are
required to support DNS resolution, which includes MX
resolution. 

At the moment, 821bis leans strongly toward the second option,
but may not do that clearly enough to leave no ambiguity.
Anyone want to argue for the first or third approach?  Or to
propose text for any of the three?

   --john