Subject: Re: FWD: Re: To MX or not to MX?

From: John C Klensin <[email-masked]>
Date: Fri, 05 Mar 1999 17:17:52 -0500 (Eastern Standard Time)

On Fri, 05 Mar 1999 01:34:55 -0600 Pete Resnick 
<[email-masked]> wrote:

> On 3/5/99 at 1:17 AM -0500, John C Klensin wrote:
> 
> > Let's assume I'm an ISP and I'm setting up a "send me everything" 
> > relay for my users, who might be using a variety of clients.
> 
> OK, so you are starting out by assuming that your users are going to 
> have clients that, by definition, do not follow the MX rule. That is, 
> they are not going to take each recipient in the message, discover 
> the right hand side of the address, and use the MX rule to deliver to 
> that address. Instead, they have a configuration box that says, "Type 
> in your relay information here [leaving aside for the moment what 
> that 'relay information' is] and I will deliver all mail through this 
> relay instead of through the regular MX channels." Right?

There are two possible versions of "the MX rule".  One is

   Any SMTP client has to resolve each address in 
   each message separately and send everything as specified 
   in the MX records associated with the domain names.  By 
   this interpretation, which I explicited removed from the 
   -10 draft, any use of a "send me everything" relay is 
   non- (or partially-) conformant.

the other is

   Any time an SMTP client has a name to which it    
actually intends to send something (that is, any of

      -- a client sending everything to a relay, for the 
         name of that relay
      -- a client resolving individual addresses and names
         in RCPT TO fields
      -- a client sending everything "left over" to a 
         "last resort" host, for the name of that host )

it is expected to do MX resolution on the name involved.  

There is no desire to prohibit any of those three types of 
behavior, only to specify what is done with the name.

> > -- Set up a bunch of MX records.
> 
> OK, so in this case, you are assuming that the box in your users' 
> clients is the name of one or more MX records that points, not to a 
> host or hosts that accepts mail for eventual delivery to a particular 
> domain name, but rather a host or hosts that will successfully relay 
> mail. Well, that's a neat trick to play with MX records, and is 
> certainly a feature that we've decided is useful, but let's not kid 
> ourselves here: This is just a neat hack with MX records that point 
> to nothing to which an MX record is supposed to be pointing. 

I don't see where you get "supposed to be".  With the 
exception of the recent Submit work, there is nothing, in 
any Internet Standard today, that authorizes use of a "send 
it everything" relay. Up until now, that behavior has been 
treated as a "consenting adult" situation, or, in parallel 
with the "split MUA" model of POP and IMAP, a "split" 
arrangement in which the submission SMTP server is remote.

If this remains a "consenting adult" case, then 821bis 
doesn't need to say _anything_ about it, and SMTP clients 
who send everything to one host are simply not completely 
conforming, which is the case for most things done only by 
agreement among consenting adults. That is exactly where 
the text was prior to -10, and it wasn't an accident. But 
it was causing confusion, and there appeared to be WG 
consensus behind saying something.  That "something" can 
either be a few more special cases that reach pretty far 
into the "submission MTA" model, or a notion that these 
relays exist and will be used, but are otherwise treated 
almost as implicit add-on source routes (the latter is, of 
course, how the first generations of such relays were 
implemented -- the originating MUA would take all 
instances of the prototypes for
    RCPT TO:<user@foo>
and rewrite them into
    RCPT TO:<@handy-relay:user@foo>
and then hand them off to the local MTA, which would follow 
the source routes and hand everything to "handy-relay".

> We could 
> say, "You need a MS record defined for mail submission which 
> identifies a host or hosts that can relay mail." And I take it your 
> response is, "Well, you would traverse MS records the same way you 
> are supposed to traverse MX records, so why don't we make this a new 
> use of MX records."

I would say nothing of the sort.

> So we've come up with a neat hack for MX records. It's damn useful 
> for clients to allow the relay configuration box to contain something 
> upon which they perform standard MX lookups. But no matter how 
> wonderful, I don't think it's the place of this standard to say 
> "SHOULD" for a MUA configuration option. But I think there's even a 
> better reason not to make it a "SHOULD":
> 
> >  -- I can put in an A RR and, if I want all of my users to
> >     use a single relay name (other plans tend to be
> >     administrative/management/ops nightmares), I can
> >     install some sort of address misdirector (or a kludge
> >     to fake balancing like DNS round robin) to hand things
> >     off across multiple hosts if I need more than one for 
> >     scaling.
> 
> So, whatever you do for scaling purposes in SMTP relaying, how do you 
> deal with scaling for POP or IMAP? I guess you could also use the MX 
> hack above, but then it's clearly not being used for anything vaguely 
> resembling what MXs are used for.

No, it is not.  And assigning different users to different 
ultimate mailboxes is well understood, and several 
companies have technologies for doing it that operate at 
the mail level, not the address level.  But none of this is 
SMTP, and we have never established the equivalent of a 
split-UA model for mail sending.
 
> But at many sites, including QUALCOMM, it's not such an 
> administrative nightmare to assign each user a particular POP server 
> (either by telling them or using ACAP) to distribute use. And as you 
>...

How many mailboxes/users did you say QUALCOMM has?  A few 
million?  A few tens of millions?   Sarcasm aside, 
subdomain names are cheap and it would be at least as 
rational to establish a default of "use 
relay.popserver.doma.in.com" as the relay as "use 
popserver.doma.in.com" and to build names appropriately.  
It seems to me that using MX records only for mail to 
popserver.doma.in.com from the outside, but having the 
client use an A RR for the same name to a host that isn't 
in the MX list is a clever, but bizarre, approach that 
violates several of the design principles of the DNS.  Of 
course, if the server really needs to be addressed 
differently inside and outside the firewall, you could use 
_different_ MX records on the "inside" and "outside".  I 
don't like that approach, but it is pretty popular.

> Let's I have my SMTP relay pointing at foo.qualcomm.com, which is my 
> assigned POP/SMTP-relay server. Now, of course foo receives mail for 
> me and other users on foo, and because of that there are some MX 
> records set up to handle foo's mail just in case foo is down or 
>...

You are way, far, out into the private agreements and hosts 
not accessible from the public Internet here.  Some 
question as to whether these uses are fully conforming in 
any event, but 821bis doesn't address them, any more than 
it explicitly addresses firewall traversal.  We could, I 
suppose, try to fix that... have another year?

>...
> (a) The hard part is not putting in the switch. The hard part is 
> putting in the MX code. Doing a straight A lookup as the 
other option 
> is easy to throw in.

The hard part is explaining to end users whether or not to 
use the switch.  And, again please note that, if the SMTP 
component of your client has no capability for MX 
resolution, it is non-conforming under RFC 1123.  This 
isn't a new story.

> (c) This *must be* an MUA configuration issue for how relaying works, 
> and I think we're just spinning our wheels if we try to lock down 
> doing it one way or the other.

Then, IMO, we are back on the private agreement cases, and 
821bis should not be specifying how private agreements 
work.  Or, more specifically, it shouldn't specify how this 
particular private agremeent should work without specifying 
all of the other private agreements too.  I note, for 
example, that your client can be configured (may still 
default) to letting the next-hop relay set the date and 
time in the 822 header, which is clearly a violation of 822 
and 1123.  It isn't conforming, and no one cares much 
because it is viewed as a private agreement matter.

"These first-hop relays are all a matter of private 
agreements which may not be conforming" really is my 
preferred way to handle this mess.  If one goes that route, 
one can use MX records or not, A records or not, or WINS 
resolution for all I (or the specification) care.  But, if 
the WG wants statements about doing this in a conforming 
way, I don't see how those statements can be "you can do 
this (or not), and you can interpret names and addresses 
any way you like" in the context of conformance -- that is 
the "no interoperability without an agreement about 
profiles" case.
 
> Nope. I think picking is a VERY BAD thing in this situation. I don't 
> like your horn; you don't like mine; they're both equally pointy. 
> Describing this particular bovine's head might be a good thing, but 
> the impalement in this standard does nothing for me.

We might even be in agreement.  See above and the note to 
Brad.

     john

---

From: "Randall S. Winchester" <[email-masked]>
Date: Sat, 6 Mar 1999 04:09:41 -0500 (EST)

What is in an MX....

1) I expect everyone outside my domain to use my "published" MX addresses
when sending mail to my domain.

2) Inside my domain I most often do not send or route mail to those
"published" MX addresses. There are strong performance and service reasons
for doing this. I have only so many machines to handle all the mail that
millions of internet hosts may choose to pass my way. I have separate
machines to handle the mail that my domain sends internal and to the
internet. My domain's mail must go through..

3) I consider my domain to include my customers on travel, at home, or
otherwise connecting to my mailservices from other ISP's. I do not expect
them to use the "published" MX addresses, which may be overrun by the
millions of hosts on the internet, but rather those addresses that I can
guarantee will be available when they need to connect back to my/our
domain.

4) (beyond the MUA issue) I run "sendmail -bd" daemons configured to, at
least, listen to localhost:25. Any other sendmail process started on those
machines talks SMTP to localhost:25 (I do not need a setuid binary). Those
machines which do not listen for incoming SMTP connections (the vast
majority) typically forward mail to my domains internal SMTP servers. There
is no need, or desire, to do an MX lookup for any of that. I run 1000
machines this way.

5) When support for authenticated SMTP exists, my "unpublished" (non-MX)
mailservers will use it to insure that 1) can be more tightly controlled.
I see MX's as a requirement for the unauthorized, but it is all SMTP.

I do not know how you want to write or phrase it, but my view on this is;

a) If you have the consent of the responsible party for a given address,
you MAY choose not to use MX lookups when forwarding to it.
Most MUAs and many intra-domain SMTP servers are in this category.

b) If you do not have the consent of the responsible party for a given
address, you MUST use MX lookups when forwarding to it.
Most inter-domain servers are in this category.

>From my perspective, I feel this is a clear take on the issue.

Randall

---

From: Robert Elz <[email-masked]>
Date: Sat, 06 Mar 1999 22:50:32 +1100

Date:        Fri, 05 Mar 1999 17:17:52 -0500 (Eastern Standard Time)
    From:        John C Klensin <[email-masked]>
    Message-ID:  <[email-masked]>

  | There are two possible versions of "the MX rule".  One is
	[ standard MX use ]

  | the other is

	[ weird and very unusual indeed]

The first is how MX is supposed to be used.   I would have been quite
happy to leave things that way.

However, if we have to change, it doesn't have to be to the second of
those - we can leave MX's alone, and simply not make it non-conformant
(as opposed to just outside the scope) to forward mail to a relay.

  | I don't see where you get "supposed to be".  With the
  | exception of the recent Submit work, there is nothing, in
  | any Internet Standard today, that authorizes use of a "send
  | it everything" relay.

That's irrelevant.   MX's are for resolving mailbox domains.   If you
have user@domain, you look up domain for its MX record, and connect to
the SMTP server at the domain name obtained.   That's the extent of their
intended use.   They're not intended to be used as an indirection step
for anything else at all.

  | If this remains a "consenting adult" case, then 821bis
  | doesn't need to say _anything_ about it,

which would be fine by me, but it seems tha a lot of people don't understand
"outside the scope of this standard" and insist that if there's a doc on
X it must cover absolutely everything even partially related to X.  If we
simply have to go along with that to get rough consensus, at least we ought
say the right thing, and not the wrong one.

  | relays exist and will be used, but are otherwise treated
  | almost as implicit add-on source routes (the latter is, of
  | course, how the first generations of such relays were
  | implemented -- the originating MUA would take all
  | instances of the prototypes for
  |     RCPT TO:<user@foo>
  | and rewrite them into
  |     RCPT TO:<@handy-relay:user@foo>
  | and then hand them off to the local MTA, which would follow
  | the source routes and hand everything to "handy-relay".

That's certainly an option - in fact, that is (approximately, the %
hack is actually used instead of source routes) how the IETF mailing
list is delivered to Australia.   For that, lookup of "handy-relay" for
its MX value is most certainly required.   But this is not an MTA issue,
as far as it is concerned it has the address given, which includes 
"handy-relay" as the (pertinent) domain name part.

On the other hand, if an MTA is being configured to simply ignore the
addresses it is handed (or all but some of them, or some specific ones)
and connect to a specific host's SMTP port to deliver the mail, then it
ought not be doing MX lookups at that point.

  | It seems to me that using MX records only for mail to
  | popserver.doma.in.com from the outside, but having the
  | client use an A RR for the same name to a host that isn't
  | in the MX list is a clever, but bizarre, approach that
  | violates several of the design principles of the DNS.

I think you are missing the point.   It has nothing at all do do with inside
or outside.   Clients inside (not configured to simply forward such mail
to a specific relay) should also be using MX records if mail happens
to be addressed to popserver.doma.in.com.

The difference is in how that name is obtained.   If it is an e-mail
address, then MX lookups are done.   Otherwise they are not.  The same
would be true if someone from "outside" were configuring their mailer to
simply forward all mail to popserver.doma.in.com (or perhaps they were
configuring their mailer to forward all mail for doma.in.com to that server).

That is, if you like, you can consider relay configuration as an override
on the DNS MX lookup, specifying a -1 preference MX record for some set of
destinations (perhaps all).  (where the -1 is truly meant as a signed number,
with all MX's returned from the DNS being unsigned in the range 0..65535,
and -1 comparing less than 0).

  | Of course, if the server really needs to be addressed
  | differently inside and outside the firewall, you could use
  | _different_ MX records on the "inside" and "outside".  I
  | don't like that approach, but it is pretty popular.

This is a different issue - where people inside their space want mail
delivered following different rules than people outside.   It is related,
but not at all the same thing.

  | Then, IMO, we are back on the private agreement cases, and
  | 821bis should not be specifying how private agreements
  | work.

I agree.    On the other hand, implying anywhere that MX lookup should
be done for anything other than mailbox domain names would be a very bad
mistake.   Not implying that doesn't mean that it can't be done by private
agreement if that is what some consenting systems desire to do, but this
doc should most certainly not be implying that this is a role for which MX
records were intended.

kre

---

From: Ofer Inbar <[email-masked]>
Date: Mon, 8 Mar 1999 20:45:15 -0500 (EST)

> for anything else at all.
[...]
> ought not be doing MX lookups at that point.
[...]
> address, then MX lookups are done.   Otherwise they are not.  The same
[...]
> and -1 comparing less than 0).
[...]
> doc should most certainly not be implying that this is a role for which MX

The above pretty much summarizes what I would have written if kre
hadn't written it first.  Of course private agreements can result in
weird uses of MX for such things as indirecting mail submission names,
but that is not what MX was meant for and it is not what MX is used
for today.  "The MX rule", however it is stated, should make it clear
that as far as the SMTP protocol is concerned, the purpose of an MX
record is *only* to map mail domains to delivery addresses, and *not*
for any other kind of indirection.  That describes current practice
for mail submission, even though submission is not always conforming
to SMTP.  Hopefully it won't be too long before a mail submission
protocol using SRV records comes into use, and that will allow the
indirection John Klensin would like.  In the meantime, he can of
course use MX for this purpose, as long as it's by explicit agreement
with all his clients.  But in absence ob explicit agreement to use MX
for this purpose, SMTP clients should not us MX for any purpose other
than resolving the final mail domain to a delivery address.

In other words, SHOULD NOT use MX in the relay case, if there's any
language about it in the draft.

  --  Cos (Ofer Inbar)         -- [email-masked] [email-masked]
  --  The Left Bank Operation  -- [email-masked] http://www.leftbank.com/
 "OSI is a beautiful dream, and TCP/IP is living it!"
   -- Einar Stefferud <[email-masked]>, IETF mailing list, 12 May 1992

---

From: [email-masked] (Claus André Färber)
Date: 11 Mar 1999 19:44:00 +0100

John C Klensin <[email-masked]> schrieb/wrote:
> preferred way to handle this mess.

This solution is sensible. But then the standard must not suggest other  
behaviour. It is worth nothing if the standard says: "do MX lookups"  
when this is always overridden by private agreements.

-- 
Claus Andre Faerber <http://www.faerber.muc.de>
PGP: ID=1024/527CADCD FP=12 20 49 F3 E1 04 9E 9E  25 56 69 A5 C6 A0 C9 DC