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

From: John C Klensin <[email-masked]>
Date: Wed, 03 Mar 1999 22:13:03 -0500 (Eastern Standard Time)

Hi.  

Kelley sent the referenced note to me, and then separately 
sent it to the list.  Assuming it was private, I answered 
privately. 

Basically, as I tried to indicate in the posting about -10, 
there was a communications disconnect about this issue, 
with different of us talking about different cases.  I 
think the text is now clear, and would really appreciate it 
if people would go look at -10 and the explanation I sent 
out last week before kicking the dead horse harder or 
longer.

To reprise, there are two separate issues under discussion:

(1) Q: Is is ok for clients incorporating an MUA (aka SMTP 
Originators) to send everything to a "first resort" 
host/replay, rather than to the mailbox/domain-designated 
target?
    A: Yes.  No one has tried to prohibit this, and the 
text is, I hope, now clear.   If it isn't, I don't need 
convincing about the topic, only suggested text.

(2) Q: If such a client is configured with the name of the 
relevant relay, should _that name_ be processed as an SMTP 
host, i.e., subjected to MX resolution.
    A: Most of us who have been responding to that question 
believe the answer is "yes", and the text now, I hope, says 
that.

Again, please read the new material in -10 before spending 
a lot more time discussing this.

     john

--- Begin Forwarded Message ---
Date: Wed, 3 Mar 1999 17:53:34 -0500 (Eastern Standard Time)
From: John C Klensin <[email-masked]>
Subject: Re: To MX or not to MX?

To: "R. Kelley Cook" <[email-masked]>

On Tue, 02 Mar 1999 17:47:21 -0500 (EST) "R. Kelley Cook" 
<[email-masked]> wrote:

> On Thu, 18 Feb 1999 22:22:11 -0500 (Eastern Standard Time), John C
> Klensin wrote:
> 
> >It seems to me that the essence of an IETF protocol 
> >specification ("protocol" used somewhat more broadly than 
> >you use it above) is to specify conditions under which 
> >functional and effective interoperability can occur on the 
> >Internet. 
> 
> John,
> 
> I disagree with this assertion.  If you are on a dial-up connection to
> your ISP, who is connected to directly to the internet, you could
> reasonably assume that your computer is connected to the internet and
> therefore has to conform to IETF regulations.  
> 
> However, your stance for a MUST the MX lookups, does not conform to how
> things operate now.  The vast majority of MUAs only relay information
> to their ISPs (MX aware) SMTP server using everything in the current
> SMTP protocol EXCEPT for MX lookups since there MUAs have been
> configured to always send to one particular server.

Please read -10 and the associated notes (section X.1.10, I 
believe) on this subject.

> By requiring MX lookups, will you exclude the vast majority of users of
> RFC822 by eliminating all currently compliant MUAs from the scope of
> RFC822bis since they don't -- yes.

Not at all.

> Does anyone realistically want MX lookups to be done by all MUAs -- I
> am quite certain the answer is no.

Yes.  But, in the case you cite,  MX lookups on the name of 
the first-hop "send everything there" relay, not on the 
final target.  Remember, I work for an ISP and a 
reasonably large one at that, so I'm not totally naive 
about this.

> In that case, must we write a separate document for how MUAs are
> supposed to talk to their ISPs relaying SMTP server -- I hope not,
> since it will be 99% the same as 822bis.

As a separate effort, such a doc already exists.  Check the 
RFC index for Gellens and Klensin on a mail submission 
protocol.

> IMO, Dans suggestion was quite good, IMHO.  Require SMTP authentication
> either by trusted host or MX lookups.

Impossible at this time.  Check WG charter.  It _would_ be 
possible for an ISP to impose this requirement on 
communication between their clients and the first-hop 
"submission" relay, but that is a business arrangement, not 
a protocol one.  And, if I were an ISP considering it, I'd 
seriously consider requiring use of "submit".

Please post suggestions for protocol-level changes to the 
WG, not in private notes to me.

    john

--- End Forwarded Message ---

---

From: "D. J. Bernstein" <[email-masked]>
Date: 4 Mar 1999 05:37:01 -0000

John C Klensin writes:
> believe the answer is "yes",

There's no nice way to say this: Klensin is out of touch with reality.
He is misrepresenting the users, misrepresenting the implementors, and
misrepresenting the working group.

And yet he wins by default unless the rest of us go to extreme effort.
His editorial procedures are blatantly biased in favor of his own views.

---Dan

---

From: Pete Resnick <[email-masked]>
Date: Thu, 4 Mar 1999 00:11:41 -0600

> believe the answer is "yes", and the text now, I hope, says

The text currently says:
---
A relay SMTP server may be encountered in one additional circumstance: by
private agreement between an originating client SMTP and an associated
SMTP relay, the client MAY be configured to send all mail to that relay
for further processing.  In conformance with this specification and other
Internet Standards and guidelines, the relay SMTP SHOULD be configured
into a client of this type by name (rather than by IP address), and the
name SHOULD be processed as described in section 5.
---
Though there are clearly environments in which MX processing is 
appropriate, there are many environments (perhaps the majority of 
existing environments) where such processing is inappropriate. This 
is likely the case because for a very long time, such clients were 
not able to do MX processing and therefore the environments were set 
up to accomodate this. However, this still remains the case, and (for 
example) Eudora, which is now able to do MX processing, still has its 
default setting *not* to do so because it is not appropriate in most 
environments.

I don't think that this statement on simple originating clients 
should have a "SHOULD" when it comes to "section 5 processing". I 
think a "MAY" is more appropriate in this case.

I certainly think that clients SHOULD use names rather than IP 
addresses and that statement should remain as-is..

pr
--
Pete Resnick <mailto:[email-masked]>
Eudora Engineering - QUALCOMM Incorporated
Ph: (217)337-6377 or (619)651-4478, Fax: (619)651-1102

---

From: Dave Sill <[email-masked]>
Date: Thu, 4 Mar 1999 08:25:07 -0500 (EST)

>host, i.e., subjected to MX resolution.

No. Standard practice currently is to *not* apply MX resolution in
this case. Encouraging that via "SHOULD" is inappropriate.

-Dave

---

From: Robert Elz <[email-masked]>
Date: Fri, 05 Mar 1999 01:41:29 +1100

Date:        Wed, 03 Mar 1999 22:13:03 -0500 (Eastern Standard Time)
    From:        John C Klensin <[email-masked]>
    Message-ID:  <[email-masked]>

  | (2) Q: If such a client is configured with the name of the 
  | relevant relay, should _that name_ be processed as an SMTP 
  | host, i.e., subjected to MX resolution.
  |     A: Most of us who have been responding to that question 
  | believe the answer is "yes", and the text now, I hope, says 
  | that.

John,

That is simply wrong.

MX resolution is used to turn the domain name part of a mailbox into
the domain name of the mail server that receives mail for the first
named domain.

That's all it is for.

If I am supposed to do MX lookup on a SMTP server name I have before
connecting to the server, then it stands to reason that I should do that
even if the name I have came from an earlier MX lookup.  That is not at
all how MX lookups are done.

I would go further than some of the others who have replied and say that
not only should the text not say that MX lookup SHOULD be done, it should
actally say that MX lookup MUST NOT be done in this case.

That is, a configured mail server name should stand as equivalent to a
mail server name obtained after an MX lookup of the domain name part of
an e-mail address.

While I am here...   in some recent messages people have been bandying about
the terms "client" and "server" as if they meant MUA and MTA.   They don't.
Every SMTP transaction is between a client and a server - the client is the
one who initiates the conversation (opens the connection and says HELO, or
if it must, EHLO), the server is the one that receives the connection and
sends the messages with the 3 digit numeric tags.   Both of those are MTAs.
SMTP is all about communications between MTAs.  SMTP has never specified
how a MUA manages to get its message to an MTA, that's a local issue, and 
always has been (and that should certainly not be changed here - which isn't
to say that others can't write specs for various standard ways of accomplishing
the task).   If the MUA chooses to simply drop the message in a magic directory
for the MTA to find, that is absolutely fine (as is dialing the phone and
sending via uucp, or making something that looks like a SMTP connection to
an MTA).

I do appreciate the point that Philip Hazel (and others I expect) made that
the "SMTP" name is lost, and that MUAs which connect to port 25 on their
nearby mail submission host (MTA) believe that they are using SMTP - and that
attempting to change that now would be hopeless.   I'm not 100% sure of
the last part - get a new doc with a new name (even if almost none of the
details are different from SMTP) and I think it would not take long for
people to adjust to using the new terminology ("submitting mail via SMTP is
the old way, I use the new MSP instead, you should too") even though the
two might be almost functionally identical.

I don't believe that matters however, whether the users believe they're using
SMTP or not as a mail submission method is immaterial - no-one is intending
changing anything which in any way affects how MUAs submit mail (as the SMTP
doc simply says nothing at all about how MUAs work or interact).

The only case where "MUST do MX lookup" might be inappropriate is in the
case where an MTA is configures to simply send all its mail (or all except
some of its mail, or something) to another MTA for processing (for getting
outside a firewall, or for some special processing of mail to one
particular destination is to be treated, etc).   For that reason I can
tolerate SHOULD do MX lookups rather than MUST - the behaviour of MUAs
or the beliefs of their users has nothing at all to do with it.

kre

---

From: [email-masked] (Lee Thompson)
Date: Thu, 04 Mar 1999 17:28:00 GMT

>  | believe the answer is "yes", and the text now, I hope, says 

Having clients do MX lookups, in my opinion, is silly - if the client is doing
MX record lookups to send mail, why is it sending the mail to the local
server?  It might as well send it to the target system directly.

_
Lee Thompson                       [email-masked]
Seattle Lab Inc.           http://www.seattlelab.com
Product Manager

---

From: Philip Hazel <[email-masked]>
Date: Thu, 4 Mar 1999 17:52:02 +0000 (BST)

> the domain name of the mail server that receives mail for the first

I agree. I think I said this before, but I'll add it again to reinforce 
these recent postings:

MX records are for turning mail domains names into MTA host names.
A records are for turning MTA host names into IP addresses.

What we have here is an MTA host name - the name of the host to which 
the client is to send all outgoing mail. Therefore the DNS lookup should 
be for an A record, not an MX record.

> all how MX lookups are done.

Quite!

-- 
Philip Hazel            University of Cambridge Computing Service,
[email-masked]      Cambridge, England. Phone: +44 1223 334714.

---

From: John C Klensin <[email-masked]>
Date: Thu, 04 Mar 1999 13:28:24 -0500 (Eastern Standard Time)

> server?  It might as well send it to the target system directly.

The arguments for it are that:

(i) it makes the behavior of an originating client SMTP 
that uses a single relay more nearly like that of an 
"ordinary" originating SMTP client and that of a relay 
SMTP.

(ii) It facilitates the operator of the relay service 
specifying alternate servers for, e.g., scaling purposes 
(remember that multiple MX records at the same level are 
expected to be tried in random sequence, while multiple A 
RRs are expected to be tried in order) without 
reconfiguring clients.

Clearly all of the notes posted since I posted the comments 
on this express the belief that either neither of the above 
are worth the trouble or that there is different logic that 
makes the above irrelevant and that MX resolution on the 
name of the relay should not be done.    Unless others 
disagree, I will change it in the next version.  I really 
don't feel very strongly about the answer here; I do 
believe it is important that the spec take a position and 
not leave the expected behavior ambiguous

    john

---

From: Ofer Inbar <[email-masked]>
Date: Thu, 4 Mar 1999 14:23:13 -0500 (EST)

> the domain name of the mail server that receives mail for the first
[...]
> actally say that MX lookup MUST NOT be done in this case.

I agree with this.  I would prefer a SHOULD NOT.  There's no good
reason to actually prohibit doing MX resolution in this case, and for
a large ISP, as John has pointed out, there may be a good reason to do
so.  But I believe the standard should be pretty clear that this is
not what MX resolution is for, and the "normal" way of implementing
SMTP would be to NOT do MX lookups in the case where a specific mail
server name has been configured administratively into the client MTA.

  --  Cos (Ofer Inbar)         -- [email-masked] [email-masked]
  --  The Left Bank Operation  -- [email-masked] http://www.leftbank.com/
    "Hey, this is com-priv, _the_ place for irrelevant discussions!"
       -- Vadim Antonov <[email-masked]>, on com-priv 06Jan1997

---

From: Brad Knowles <[email-masked]>
Date: Thu, 4 Mar 1999 19:54:41 +0100

On Thu, Mar 4, 1999, John C Klensin <[email-masked]> wrote:

>name of the relay should not be done.

    I would be inclined to say that it MAY be done, and to outline the
reasons you gave (which I have deleted) as explanation for why MUA
authors may choose to implement that feature.  However, I would not want
the wording any stronger than "MAY" in this case.

>                                                 I really 

    Agreed.  Thanks for all your hard work!

-- 
  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: "R. Kelley Cook" <[email-masked]>
Date: Thu, 04 Mar 1999 14:33:49 -0500 (EST)

>addresses and that statement should remain as-is..

Agreed fully.

---

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

> server name has been configured administratively into the client MTA.

Sorry, but I disagree, although probably not in the way 
that you'd expect.  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.   Now, I can:

-- Set up a bunch of MX records.
    But, if I do, I need to know that every one of those 
    clients will do MX resolution of the names, or at least 
    that those who don't are broken.  I.e., if the clients 
    don't have at least a "SHOULD do MX", then my using MX 
    records on the server/services side is an 
    interoperability threat, especially if there are no A 
    RRs associated with the name.  I suppose that we could 
    introduce a requirement for such an A RR (in addition 
    to the MX RRs) in this case, but I don't think we want 
    to go there.

 -- 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.   No MX RRs in this case, they just 
     complicate things.

IMO, the second stinks architecturally, but I'll put it in 
the spec if that is what the WG wants.

But the idea of saying "maybe you do and maybe you don't" 
impresses me as a really poor idea.  The first case implies 
that the server-side really needs to know/be able to 
predict what the client side will do.   That can either be 
in the protocol --in which case we need to write something 
(one choice or the other) definitive into the spec -- or it 
is a matter of private agreements between the client and 
the server.

The latter option has two implications:

* We don't need to say anything (or much of anything) in 
   the spec, since such private agreements are generally 
   out of scope for the standard, other than indicating 
   they might occur.

* Since, in the ISP-and-customer case, this "private 
  agreement" will almost always be one in which the server 
  operator will tell the client/user/customer what is 
  expected/permitted (rather than negotiating the 
  agreement), client program authors who want to have 
  their tools be useful/salable into both "MX" 
  and "no MX" environments will have to build both in and 
  include a switch.  That is unnecessarily hard and creates 
  opportunities for non-interoperability and customer 
  support nightmares.

So, one way or the other, I think we need to pick.

   john

---

From: Pete Resnick <[email-masked]>
Date: Fri, 5 Mar 1999 01:34:55 -0600

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?

> Now, I can:

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

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":

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

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 
know, by default Eudora uses the POP host to do SMTP relaying unless 
configured otherwise. And it is cases like these (which I think is 
still how the majority of ISPs work) where the dealing with the SMTP 
relay as an MX could be absolutely disastrous:

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 
someone outside the firewall sends mail to me at foo, which is inside 
the firewall. You see, those MX machines are big mondo machines that 
sit outside the firewall and handle all of the incoming mail for 
QUALCOMM and distribute it all over the place. But foo, being inside 
the firewall, knows some things that those big servers don't, like 
private internal-to-QUALCOMM-only addresses/redirecters and perhaps 
some other ugly internal QUALCOMM things. If Eudora goes and treats 
"foo.qualcomm.com" as an MX record and foo itself happens to be down, 
my mail is going to be relayed through hosts that can't deliver 
certain mail, or might even screw up where things are going. And I've 
had this happen. And it's been very bad. And if Eudora didn't default 
to using the SMTP relay host as an A record instead of an MX record, 
we'd have a bunch of very pissed-off customers.

> the spec if that is what the WG wants.

No, I think saying that clients MUST use A records (or even SHOULD) 
is probably a bad thing too.

> is a matter of private agreements between the client and

I think it is a matter of private agreement. Many clients can't do 
the MX game now, and I think it's useless to try to get them to do so 
by saying SHOULD in the standard when there are damn good reasons to 
go either way.

>    out of scope for the standard, other than indicating

True, but I think it's worth noting that the functionality could be 
useful for just the case you cite, and note that you would use the 
same MX-like rule that appears in section 5.

>   opportunities for non-interoperability and customer

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

(b) The interoperability and support nightmares are going to be there 
anyway since there are two cases (your's and mine) which are equally 
bad if you use the wrong setting.

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

> So, one way or the other, I think we need to pick.

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.

pr

---

From: Philip Hazel <[email-masked]>
Date: Fri, 5 Mar 1999 09:25:29 +0000 (BST)

On Fri, 5 Mar 1999, Pete Resnick wrote:

> This is just a neat hack with MX records that point 

This is a meta-comment:

The problems we are currently wrestling with all stem from the fact that 
the DNS started out by registering only *hosts* (A records) and then, 
because it really needed to, added a facility for registering one 
particular type of *service* (mail exchangers). So it really is in 
half-cocked state, and people use name extentions (e.g. www.xxx) to 
indicate that what looks like a host name is really a sort of service 
name (and then have to rely of "well-known" port numbers).

<pie-in-the-sky>
The right way to fix all of this would be to start again, and start 
registering services rather than hosts. Then, for a given domain name 
a.b.c.d you could have a number of different types of record for the 
services that are accessible using that name (mail delivery, mail 
submission, www accesss, imap access, etc. etc.) And all of them could
be defined in a multiple way, like current MX records, so it would be
easy to set up backups for all your services, not just mail delivery.
Wouldn't a lot of people like an easy way to run backup www servers?
But I guess it's far too late, and this is just PITS.
</pie-in-the-sky>

---

From: Robert Elz <[email-masked]>
Date: Fri, 05 Mar 1999 20:36:53 +1100

Date:        Fri, 5 Mar 1999 09:25:29 +0000 (BST)
    From:        Philip Hazel <[email-masked]>
    Message-ID:  <[email-masked]>

  | The right way to fix all of this would be to start again, and start 
  | registering services rather than hosts.

See RFC2052.

That is an expermiental RFC, but a (slightly modified) variation is
should soon be done and published as PS.  (see
draft-ietf-dnsind-rfc2052bis-02.txt - there will be one more draft to
deal with some IESG issues before it is published as an RFC, the IETF
last call has already completed).

Some other (new) services are already starting to specify use of the SRV
record.   It would be entirely reasonable for a mail submission type
protocol to do the same.

kre

---

From: Brad Knowles <[email-masked]>
Date: Fri, 5 Mar 1999 18:32:31 +0100

>the impalement in this standard does nothing for me.

    Frankly, I don't think it's realistic to expect a large number of
MUAs to do MX lookups.  It just ain't gonna happen.  From a purely
aesthetical point of view, I liked the idea of allowing them to do MX
resolution, but I now realize that is not realistic.

    Although you can do the visible separate POP/IMAP server thing and
segregate your customers by server, in my experience that just leads to
confusion and the *last* thing we want to do is confuse the users.  IME,
You're better off going with a front-end/back-end server solution that
will retain the appearance of a single host (using DNS round-robin and
NAT or layer four switches) to hide multiple hosts behind a single name. 
You can separate the POP3/IMAP servers from the outbound mail relays, but
it is not strictly necessary (although I think it's a good idea).

    Unfortunately, MXes don't scale all that well, either.  Once you get
to hundreds of inbound mail machines for your domain, you can't
realistically list all of them in your replies, so you end up having to
use either DNS or NAT/switch tricks to get back down to a smaller subset
that any one sender might know about at any one particular point in time.

    Based on what I've seen here so far, If I have to choose between
SHOULD and MAY (or SHOULD NOT), I would vote for SHOULD NOT.

    I think we should explicitly state that how MUAs would deliver mail
to their upstream servers is a private arrangement issue (since, as far
as we're concerned, they're not truly on the Internet and we're not
expecting them to do MX resolution), and then we should describe some
typical private arrangements.

    As Pete points out, there are just too many different ways in which
things might radically vary at different sites, and I don't think that it
would be a good idea to try and encourage the adoption of any one of
those alternatives to the detriment of any other.  There's just too many
"legacy" systems out there that probably wouldn't conform to any solution
we might recommend (whatever that might be).

    How these guys go about doing their business has been unregulated and
pretty much undocumented for too long, for us to come along at this late
stage and try to impose our view of order upon them.

    Now, when it comes to the Message Submission protocol (whatever that
might be), I think this would be an ideal time to make use of SRV
records.  But I think this is a matter for a different document, if not a
different group.

---

From: Brad Knowles <[email-masked]>
Date: Fri, 5 Mar 1999 18:20:21 +0100

On Fri, Mar 5, 1999, Philip Hazel <[email-masked]> wrote:

>registering services rather than hosts.

    You've got this today.  They're called SRV records.  Hardly anyone
uses them yet (because they're so new), but they exist and are handled
properly by current versions of BIND.

---

From: Peter Koch <[email-masked]>
Date: Thu, 04 Mar 1999 20:40:28 +0100

> RRs are expected to be tried in order) without 

RRs in an RRSet have no defined order, so the client may try them in any
order, including that just received from the nameserver/next hop resolver.

The MX resolution for the smarthost's hostname would be more like recursive
MX processing, which does not exist.

-Peter

---

From: Bart Schaefer <[email-masked]>
Date: Thu, 4 Mar 1999 07:56:14 -0800 (PST)

> think a "MAY" is more appropriate in this case.

I agree.

---

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

> believe the answer is "yes", and the text now, I hope, says

This is plain wrong. If the standard says so, every sensible MUA author  
will have to ignore it.

It is quite common now to have different hosts for outgoing and incoming  
mail for several reasons (preventing relay attacks, load-balancing,  
firewalling etc.).

If clients did an MX lookup, this is simply made impossible. You could  
not configure clients to send outgoing mail to mailout.example.com  
because that would become mailin.example.com by MX lookup.

Normally, in such a situation you would want incoming mail for  
*@*.example.com to go to mailin, even mail to [email-masked]  
(again for security and administative reasons -- mailout might not even  
be reachable from outside), so setting up a different MX for mailout is  
not an option.

There is no good reason to change the RECOMMENDED behaviour here but  
there are enough reasons to keep it as it is.

For easier management, one might be tempted to say MX lookups should be  
done. However, there is no reason to overload MX records for that  
purpose, as CNAME records exist (and are usually honoured, aren't they?)  
to set symbolic names such as mailout and there are other protocols,  
such as SRV records to locate one of several smarthosts.

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

---

From: [email-masked] (Kai Henningsen)
Date: 21 Mar 1999 20:12:00 +0200

> believe the answer is "yes", and the text now, I hope, says

My impression was that most believe the answer is "no". As has been  
pointed out repeatedly, the "no" version certainly seems technically  
superior.

In short, I object to this.

MfG Kai

---

From: Randall Gellens <[email-masked]>
Date: Tue, 30 Mar 1999 15:04:36 -0800

>two might be almost functionally identical.

RFC 2476 ("Message Submission") specifies MSA, Message Submission 
Host, as the name of the server to which the MUA connects (via port 
587 instead of 25 in most cases) to drop off mail for further 
processing and relay.  The protocol is called Submission.

---

From: Randall Gellens <[email-masked]>
Date: Tue, 30 Mar 1999 15:30:05 -0800

>name SHOULD be processed as described in section 5.

I'd suggest (I changed the order of some clauses, replaced a comma 
with a semicolon, and added some text):

A relay SMTP server may be encountered in one additional 
circumstance: by private agreement between an originating client SMTP 
and an associated SMTP relay; the client MAY be configured to send 
all mail to that relay for further processing. In conformance with 
this specification and other Internet Standards and guidelines, a 
client of this type SHOULD be configured with the SMTP relay by name 
(rather than by IP address). Normally, a client of this type does not 
use MX record processing (as described in section 5). Note that RFC 
2476 specifies a protocol for use by clients of this type.