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

From: Steve Hole <[email-masked]>
Date: Mon, 1 Feb 1999 21:25:51 -0700

I'm replying to John's original message.    Interesting retoric from 
clearly superior lifeform server implementors over stupid MUA writers 
added too much noise to the conversation to be useful.

Not that I have an opinion ...

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

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

The combination of (1) + (3) is the norm for most GUI based MUA's. 
(2) is rarely performed because there are is a distinct lack of direct 
resolving capabilities on two key client platforms (Windows and 
Macintosh).     You can find bind libraries that theoretically run on 
these platforms, but they are *extremely* buggy.    The lack of a 
threadable source code base in the bind release has been a real problem 
for many implementors.    So, unless you are into writing your own DNS 
lookup and resolver code, you have a problem.

Of course, a threadsafe version of bind is either in the works or possibly
completed now.   That should make things better for using (2) in future 
products, but we need to wait to see if/when it gets stable enough for 
use in the real world.

On the usability front, getting users to use an MX domain name to resolve 
a submission MTA is a very interesting exercise in frustration.   They 
just don't get the concept of a server acting as the injection point for a
domain.   They do understand a hostname.    Of course, a decent 
implementation can autoconfigure the domain name and most users will never
see it.   It is interesting how often they get totally confused by this.

Finally, it is often very advantageous to configure an MTA that is not a 
"published" MTA for a domain.    Why?   To get around relay restrictions 
placed on the advertised MTA when you are connecting from outside the 
organization.   Of course, authenticated SMTP (submission) is a better way 
to do that, but it is taking some time to deploy SMTP AUTH.    For now 
there is a huge requirement to be able to do this.

Therefore, while you can make a recommendation that MUA's support (2), you
certainly can't make it mandatory.    At this time, SHOULD seems to me to 
be too strong because they just can't get there from here.    I echo what 
some of the other folks have mentioned and clearly differentiate the 
situation for submission from relay and have separate set of rules for 
each. 

Cheers.
---  
Steve Hole                           
Execmail Inc.
Mailto:[email-masked] 
Phone: 780-424-4922

---

From: "Barry Leiba" <[email-masked]>
Date: Fri, 5 Feb 1999 14:10:24 -0500

> "published" MTA for a domain.

Indeed; we have, for instance, a submission server that some of us use.  It's
a private submission server for our group, and it implements some special
routing that we need for our purposes.  There's no MX record pointing to it.
I would be very annoyed if the e-mail clients available to me did not allow 
me to submit to that server because the MX records cause mail to be aimed
elsewhere.  Very annoyed, indeed.  (I'm happy to say, though, that I haven't 
yet met an SMTP client implementation that causes me a problem in this regard.
That is, no client that I've tried seems to look at MX records.  >whew<)

Barry Leiba, Multimedia Messaging   ([email-masked])
http://www.research.ibm.com/people/l/leiba