Subject: stripped-down client configuration (Address, MX RRs, A RR-only?)

From: John C Klensin <[email-masked]>
Date: Sat, 30 Jan 1999 12:58:05 -0500 (Eastern Standard Time)

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

---

From: Brad Knowles <[email-masked]>
Date: Sat, 30 Jan 1999 19:28:10 +0100

>but may not do that clearly enough to leave no ambiguity.

    Two is clearly the preferred solution, but IMO it should be optional
(i.e., a recommendation no stronger than "SHOULD be implemented"). 
Number three is the absolute minimum, and I would vote for a "MUST
implement" requirement.

    Now, I feel that this also gets to the issue of initial message
submission versus transport of a message that has been previously
injected.  IMO, injection by a "dumb" MUA should not necessarily require
MX lookups, etc... while transport of a previously injected message should.

    Let's face it, most of these authors can barely get code that
compiles, much less doesn't crash very often.  We all know that the DNS
is not necessarily an exceptionally complex beast, but I think we're
asking too much of program authors to understand anything more than "look
up this host name, turn it into an IP address, and connect to it".  This
can be generally be implemented by relying on the OS, whereas the actual
MX lookup would almost certainly require application-level control.

-- 
  These are my opinions -- not to be taken as official Skynet policy
 ____________________________________________________________________
|o| Brad Knowles, <[email-masked]>            Belgacom Skynet NV/SA |o|
|o| Systems Architect, News/mail/FTP Admin   Rue Col. Bourg, 124   |o|
|o| Phone/Fax: +32-2-706.11.11/12.49         B-1140 Brussels       |o|
|o| http://www.skynet.be                     Belgium               |o|
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
                The Sky is no longer the limit

---

From: "Bart Schaefer" <[email-masked]>
Date: Sat, 30 Jan 1999 10:56:03 -0800

On Jan 30, 12:58pm, John C Klensin wrote:
} Subject: stripped-down client configuration (Address, MX RRs, A RR-only?)
}
} 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 [...]
} 
} (i) Client configuration should use an IP address
} (ii) Client configuration should use a domain name, which should
} then be processed through MX resolution, etc.
} (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.

Why is it necessary that 821bis address this at all?

In my experience (and please someone correct me if I'm wrong here) nearly
all modern clients implement something very like (iii) not because the
domain name "should" be interpreted as an A reference but because there
is simple or even automatic name-to-IP resolution available from the
operating system.

Sometimes that name resolution uses a static host table rather than DNS.
Sometimes it doesn't work at all, in which case most clients permit a
literal IP address to be configured.  Neither of these situations seems
inherently "wrong" to me.

What's the operational difference between using a preconfigured literal IP
number and using one resolved by MX lookup through an out-of-date DNS cache?

-- 
Bart Schaefer                                                   Zanshin
http://www.well.com/user/barts                   http://www.zanshin.com

---

From: Robert Elz <[email-masked]>
Date: Sun, 31 Jan 1999 06:05:14 +1100

Date:        Sat, 30 Jan 1999 19:28:10 +0100
    From:        Brad Knowles <[email-masked]>
    Message-ID:  <[email-masked]>

  |     Two is clearly the preferred solution, but IMO it should be optional

No, for internet mailers, name->mx->a is the only acceptable path.

Other applications are free to implement something that looks like
821bis if that suits their needs (to get mail to an internet mail
client for delivery to the world perhaps), but if they're going to
be claiming to be an internet mail client they must use name
resolution that actually can get mail delivered on the internet.

Also note that there isn't any one to one mapping between 821bis clients
and hosts, or mail implementations, or whatever.   It is entirely possible
to have an 821bis client that is distributed among all of the hosts in
an organisation (or any other set), possibly making use of code fragments
from many different vendors.   The communication methods that system
uses internally are its own business - it can be conforming 821bis,
something that looks a lot like 821bis, but does things here and there
differently, or it can be nothing like 821bis at all.

Our purpose here is not to provide a stamp of approval "821bis conformant"
that everyone who implements anything that looks kind of like a e-mail
application gets to mark on their implementation.

kre

---

From: Brad Knowles <[email-masked]>
Date: Sat, 30 Jan 1999 20:19:49 +0100

>No, for internet mailers, name->mx->a is the only acceptable path.

    As I said, I think this gets down to initial message injection versus
transport of a previously injected message.  I feel that name->mx->a is
the only correct method in the latter case, but I believe you're asking
too much of (stupid) MUA authors to expect them to handle it in the
former case.

    Any standard that makes "requirements" that are blatantly ignored for
something like this risks simply alienating the programmers, system
administrators, users, etc... that it is supposed to help serve.

    Stupid laws encourage general lawlessness, which can spill over into
truly dangerous territory (the lesson the US learned from Prohibition in
the 20s).

    I think we need to make a clean and clear break between initial
message injection and the transport of previously injected messages.  We
can do this with separate sections, we can do this with specific language
that calls out what is appropriate where, or we can do this with totally
separate standards documents.  Frankly, I don't care which, but I think
the time has come where we need to make that break.

>resolution that actually can get mail delivered on the internet.

    Then we define initial message injection to be an 821bis-like
non-Internet medium, and we avoid the problem entirely.  However, someone
somewhere is going to have to solve this problem, and it might as well be us.

---

From: Robert Elz <[email-masked]>
Date: Sun, 31 Jan 1999 07:18:03 +1100

Date:        Sat, 30 Jan 1999 20:19:49 +0100
    From:        Brad Knowles <[email-masked]>
    Message-ID:  <[email-masked]>

  | but I believe you're asking
  | too much of (stupid) MUA authors to expect them to handle it in the
  | former case.

I do not expect MUA authors (stupid or not) to routinely do MX type
delivery, in fact, in general, I much prefer that they do not.

What I want is for them to not pretend that they are 821bis compliant
however.

That's the distinction.

  |     Then we define initial message injection to be an 821bis-like
  | non-Internet medium, and we avoid the problem entirely.  However, someone
  | somewhere is going to have to solve this problem, and it might as well
  | be us.

No, it is better someone else (even if it is just us in a different room).

Let drums do what drums is supposed to do.   If we then need a local
submission standard (or even several, for this is an area where there's
no requirement that every site adopt the same method - I can use uucp
as my local submission method if I prefer) let one be defined.   Whether
that turns out to be "do just the same as 821bis, except there's no need
to implement sections a.b or ...", or whether it turns out to be quite
different is a question for some other time.

When we start getting to message submission there are lots of other
issues we may want to consider, beyond just whether MX lookups need
be done or not.   Keep all of that for elsewhere.

kre

---

From: John C Klensin <[email-masked]>
Date: Sat, 30 Jan 1999 15:39:42 -0500 (Eastern Standard Time)

Speaking as a participant, not as editor...

On Sat, 30 Jan 1999 20:19:49 +0100 Brad Knowles <[email-masked]> 
wrote:

>...
>...

You are getting a little hyperbolic in applying this argument to
this situation.  Many MUA authors do use name->mx->a, some
don't.  I suggest that it is probably useful for us to provide
some guidance as to what is expected here, and maybe the reasons
why.

>...

We can do this in the SUBMIT document?

    john