Subject: RE: regarding MX records

From: John C Klensin <[email-masked]>
Date: Thu, 11 Mar 1999 22:36:21 -0500

One set of questions, just to be sure we understand each other:

Suppose one of these private agreements is made to route mail by
mechanisms other than looking at the envelope addresses and 
evaluating their MX records.  Are such private agreements, and 
client systems configured to follow them, fully conforming to 
821bis?   Are some private agreements conforming and others not?
E.g., if I decide, privately, to dispatch all traffic between 
the originator and the consolidating relay point using PROFS, 
is that a conforming implementation of 821bis?  If not, but some
of these private agreements are fully conforming, where should 
the line be drawn.

    john

----------------

On Thu, 11 Mar 1999 18:48:30 -0600 "Woodhouse, Gregory J." 
<[email-masked]> wrote:

> I like this language. I would only add that these agreements need to be
> mutual and should be restricted to a service environment (such as a private
> network or client to host connections within a mail domain). For example, in
> the VHA network, all Internet accesss is by proxy. We have multiple mail
> systems which may wish to exchange mail (for example, Microsoft Exchange,
> and VA Mailman which is our internally developed SMTP based mail system).
>...

---

From: Brad Knowles <[email-masked]>
Date: Fri, 12 Mar 1999 09:22:43 +0100

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

>821bis?

    IMO, all private agreements are outside the scope of 821bis, and we
should explicitly mention this fact.  How they do their thing privately
is their business, and it does not intrude into 821bis territory, nor
should 821bis intrude into their private agreements.

-- 
  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: Keith Moore <[email-masked]>
Date: Fri, 12 Mar 1999 09:04:08 -0500

> of these private agreements are fully conforming, where should 

I would say that such private agreements are outside of the scope of 821bis.
I.e. it's not a violation of 821bis to have such agreements, but 
neither does 821bis try to tell you how to set up such arrangements
and how they work.  (other than perhaps to say that MX records are 
not intended for this purpose - I suppose people can use them if 
they want to, but they're meant for other things.)  And the parties 
who do set up such arrangements are responsible for whatever they create.

Keith

---

From: "D. J. Bernstein" <[email-masked]>
Date: 13 Mar 1999 18:34:30 -0000

Suppose the IETF decides to introduce a new MX scheme for some reason,
perhaps fancier load balancing.

Sites that set up the new DNS records would then be authorizing clients
around the world to try either the new scheme or the old scheme.

This is not a ``private agreement.'' But there's nothing wrong with it.
It's simply another form of authorization to send mail.

Klensin's draft artificially ties the SMTP protocol to today's forms of
authorization. It doesn't provide any name for the general concept of
``send mail to that host by SMTP.'' This immodularity will make it
unnecessarily difficult to write tomorrow's MX specs.

I've already suggested language that doesn't have this problem. ``A
client MUST NOT attempt to send mail to a server without authorization.
There are several common forms of authorization: ...''

---Dan

---

From: Robert Elz <[email-masked]>
Date: Sun, 14 Mar 1999 07:13:48 +1100

Date:        13 Mar 1999 18:34:30 -0000
    From:        "D. J. Bernstein" <[email-masked]>
    Message-ID:  <[email-masked]>

  | Klensin's draft artificially ties the SMTP protocol to today's forms of
  | authorization.

MX records are not any kind of authorisation.   They specify mail
routing.   That is, if you want to, and are permitted to, send mail
to this domain, this is where you should send it.

That I have MX records does not mean I have authorised spammers to send
mail to the hosts listed.   If it did, all my MX records would be gone
tomorrow.   Further the current rules (however nice it might be to
change them) say that if no MX record exists, an SMTP client can attempt
to connect to the A record for a mail address it has been given.   Your
"authorisation" model falls down totally there.

As for some future new specification on how mail routing ought be done
(MX replacement or something), when that appears (if that appears) its
spec would simply (by implication if necessary) revise 821bis to permit
its new form of lookups instead of (or in addition to) MX lookups.  There
is nothing at all new or strange about this, newer specs override older
ones unless they specifically say otherwise.

For now, SMTP uses MX records for mail routing, except where there is
some private agreement to do otherwise (or no MX record exists).

kre

---

From: "D. J. Bernstein" <[email-masked]>
Date: 13 Mar 1999 21:29:57 -0000

Robert Elz writes:
> mail to the hosts listed.

Surely you're not claiming that any random Internet user who sends you
mail is making unauthorized use of your computer?

In fact, the MX record authorizes _everybody_ to send mail for that
domain through the MX hosts.

If there isn't an MX record, the A record authorizes everybody to send
mail for that domain through that host.

> its new form of lookups instead of (or in addition to) MX lookups.

This means reviewing 821bis, finding all the spots where Klensin failed
to think ahead, and stating modifications to the text at each spot.

In contrast, if 821bis preserves the existing concept of ``send mail by
SMTP to that host,'' then future specs can simply _refer_ to 821bis,
without modifying anything.

---Dan

---

From: "Christian Kuhtz" <[email-masked]>
Date: Sat, 13 Mar 1999 16:35:36 -0500

> domain through the MX hosts.

This has zilch to do with authorization, Dan.  Your assumption is flawed --
to deduce authorization from public availability of, if you will, pointers
is wrong.

It is purely an informational statement, put out in good faith that it not
be abused.  Robert is entirely correct.

If I may introduce an example.. If the White House publishes its address,
that doesn't neccessarily mean that each and every one of the people who
walk through the front gate at that address are welcome and received.  If it
the 'publication event' was an authorization, nobody would be refused.

I can't wait to become your flamebait once again. *sigh*

Cheers,
Chris

--
BellSouth Corporation, Advanced Data Services,  Sr. Network Architect
[email-masked] -wk, [email-masked] -hm
"Affiliation given for identification, not representation."

---

From: "D. J. Bernstein" <[email-masked]>
Date: 14 Mar 1999 02:01:42 -0000

Right now cr.yp.to has an MX record pointing to koobera.math.uic.edu.
Suppose I also set up an A record for cr.yp.to pointing to a new host.

If someone tries to send a message through the new host, and I haven't
told him that he can do so, there's a problem.

If someone tries to send a message through the new host, and I've told
him that he can do so, there's no problem.

The only difference between these situations is authorization.

Christian Kuhtz writes:
> This has zilch to do with authorization, Dan.

If you ignore authorization then you'll never be able to explain which
servers are acceptable choices. See above.

I'm not saying that this has to be part of 821bis. In fact, I'd prefer
to see it discussed in a separate document. 821bis simply has to avoid
artificial, unrealistic, immodular restrictions on the SMTP protocol.

---Dan

---

From: Robert Elz <[email-masked]>
Date: Sun, 14 Mar 1999 17:22:47 +1100

Date:        14 Mar 1999 02:01:42 -0000
    From:        "D. J. Bernstein" <[email-masked]>
    Message-ID:  <[email-masked]>

  | Right now cr.yp.to has an MX record pointing to koobera.math.uic.edu.
  | Suppose I also set up an A record for cr.yp.to pointing to a new host.
  | 
  | If someone tries to send a message through the new host, and I haven't
  | told him that he can do so, there's a problem.

Not necessarily.   The someone would be violating the protocol, but whether
that is a problem or not is not determined by anything stated here.

  | If someone tries to send a message through the new host, and I've told
  | him that he can do so, there's no problem.

Not necessarily, but less likely.

  | The only difference between these situations is authorization.

No, the difference is whether or not you have configured the host at the
end of the A record to handle mail or not.   If you have, it works both
times.   If you haven't, it works neither time.   Whether you have
authorised anyone to make use of the mailer which is, or is not, running
at the host doesn't make the slightest bit of difference.

To give another example...   There is an MX for cr.yp.to (as you have
pointed out), but if I address this message to that host (as a cc), and
my mailer sends this message to the target of that MX it will fail,
because you haven't authorised this message to be delivered there.
That's despite the existance of the MX record, which authorises nothing.

  | If you ignore authorization then you'll never be able to explain which
  | servers are acceptable choices. See above.

The servers which are acceptable choices are the ones with MX records,
unless the sender (the sender's MTA) has been told otherwise.

And to answer a point in a previous message - yes, all the random people
who send me e-mail are making unauthorised use of my computre.   Exactly
the same as most of the random people who open the gate of my fence and
walk up to the front door are trespassing on my property.   Most of
the time no-one cares (about either) and no action is taken, those
kind of activities (while unauthorised) are expected and ignored.  Some
of the people who walk up to the door are authorised, just as are some
of the people who send me mail.   Occasionally someone might trespass,
or send unauthorised mail, in a way that might cause me to take some
action against them, rather than just ignore it (or ask them not to do
it again).   If the MX (or the front gate & path) meant "authorised"
that would be impossible - but it doesn't.

kre

---

From: Philip Hazel <[email-masked]>
Date: Sun, 14 Mar 1999 16:32:06 +0000 (BST)

This discussion has got sidetracked onto the use of the word 
"authorized" and exactly what it means. This is a diversion from the
real point of substance.

> perhaps fancier load balancing.

This is not far-fetched - maybe SRV records will become popular.

> without modifying anything.

Quite. The advantages of separating the definition of what is on the wire 
(which is normally what is meant by a "protocol" in communications 
sytems) from the rules for determining which host to send a message to
have been pointed out before. However, there is the contrasting desire 
to put "everything you need to know about email" into a single document.
This is nice in theory, but of course 821bis isn't that document - it 
contains no detail of MIME, for instance, and of course it doesn't 
contain 822bis. Personally, I think there should be separate documents
for the on-the-wire protocol and routing rules like MX. What *would* be 
useful would be a single "steering" RFC containing _pointers_ to all 
relevant email RFCs.

> the 'publication event' was an authorization, nobody would be refused.

The word "authorization" is clouding this issue. If you want to go to 
the White House, you can look up its published address. There's no 
guarantee they will let you in. Similarly, if you want to send mail to 
the domain foo.bar.com, and you have no local (private) knowledge of
where to send it, you look up its MX records; again, there is no
guarantee that the hosts they point to will accept your email. So 
neither is an "authorization to enter" in any way. 

So what are MX records, if they are not an authorization? This is what 
this list has been struggling over for some time. They are really 
nothing other than a kind of directory. In the same way as you look up 
somebody's phone number in a telephone directory, you can look up where
to send email in the DNS. You might have other knowledge about some
domain (by private agreement), which is (vaguely) like knowing 
somebody's unlisted phone number. If you do, you can try to use it. Your 
call may or may not be accepted. 

What the standard about routing mail should say is something along the
lines of the following:

  If an Internet mail host has no private knowledge of mail routing for 
  a specific domain, it (MUST | SHOULD) make use of the information in the 
  DNS to handle that domain, in the following way: <details of MX 
  processing omitted>.
  
... though I would prefer the details of MX handling to be in a separate 
RFC with a pointer. This will make it much easier to add the rules for 
SRV processing, if SRVs take off. 

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

---

From: Dave Sill <[email-masked]>
Date: Mon, 15 Mar 1999 08:25:58 -0500 (EST)

Robert Elz <[email-masked]> wrote:
>times.

Not necessarily. The SMTP server at the end of the A record could be a
test version, or wired to the bit bucket.

>If you haven't, it works neither time.   Whether you have

Sure it does. If someone uses an unadvertised SMTP server without
authorization, the transaction may succeed, but the message is not
guaranteed to reach the right mailbox.

>That's despite the existance of the MX record, which authorises nothing.

The MX record says "if you want to send mail to host x.y.z, talk to
host q.r.s." That is implicit authorization to initiate an SMTP
dialogue with q.r.s, and implicit denial of authorization to initiate
an SMTP dialogue with x.y.z. That doesn't mean, however, that every
recipient on x.y.z authorizes and guarantees to accept all mail from
all senders.

>unless the sender (the sender's MTA) has been told otherwise.

s/acceptable/authorized/

Why are you so hung up on the word "authorized"?

>walk up to the front door are trespassing on my property.

Just like the people who make unauthorized use of your phone and snail 
mailbox?

>If the MX (or the front gate & path) meant "authorised"

It means "authorized to attempt", not "authorized and guaranteed to
succeed for all possible senders/recipients/content."

-Dave