Subject: RE: editing status of 821bis, draft -10.

From: "Jeff Stephenson (Exchange)" <[email-masked]>
Date: Mon, 15 Feb 1999 16:36:45 -0800

> -----Original Message-----
> From: John C Klensin [mailto:[email-masked]]
> Sent: Monday, February 15, 1999 2:23 PM
> Subject: Re: editing status of 821bis, draft -10.
>
> ...
> Moreover, an SMTP server or relay has forward-pointing addresses
> delivered to it in domain name form.  How it figures out what to
> do with them -- and which "next hop" host to which to open a 
> connection -- is really very much part of the protocol. 
> ...
> For that reason, we could go with "relays 
> and destination servers MUST and originators SHOULD" language if
> the WG feels that would help.
> ...

I think that there is another case that needs to be considered here: the
small organization that has a local server (maybe even multiple servers) on
a LAN but a slow/intermittent/expensive connection to the rest of the
Internet via an ISP.  That organization does not want their server to do MX
resolution over their ISP link and then transfer the message to each of the
next hops for the recipients - they just want the messages sent to their
ISP's server, which will do all the dirty work.

Clearly we want the vast majority of SMTP MTAs to do the right thing with MX
resolution.  I think, however, that there are a number of very valid
topologies in which this is not the right thing to do.  Branding such uses
as non-compliant would be a mistake.

-- jeff

---

From: Brad Knowles <[email-masked]>
Date: Wed, 17 Feb 1999 04:43:43 +0100

>as non-compliant would be a mistake.

    Just because we (will presumably) require all MTAs to do the right
thing doesn't mean that they shouldn't be able to be configured in a
manner such as to avoid doing MX lookup, and to instead just dump all
outgoing mail on their ISP.

    Requiring the *capability* to do something is different from
requiring everyone to actually *do* things that way every time.

-- 
  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: Russ Allbery <[email-masked]>
Date: 16 Feb 1999 21:28:43 -0800

Brad Knowles <[email-masked]> writes:

> Requiring the *capability* to do something is different from requiring
> everyone to actually *do* things that way every time.

I thought standards were about operational behavior.  Behavior on the
wire.  Since when are standards about dictating what software packages
look like in *any* way?

I was under the impression that standards say "the bits coming across the
wire are supposed to look like the following."  If you create those bits
by whistling into a modem, what business is that of the standard?

I think the "as if" principle from the C standard applies here.  If
software performs in all ways "as if" it had done what the standard says,
then it's compliant with the standard, regardless of what it actually
does.  If software conducts a dialogue that complies with RFC 821, then
that software is RFC 821 compliant.  End of story.

This is supposed to be an interoperability standard, not a qualification
exam.

-- 
Russ Allbery ([email-masked])         <URL:http://www.eyrie.org/~eagle/>

---

From: John C Klensin <[email-masked]>
Date: Wed, 17 Feb 1999 08:59:15 -0500

> outgoing mail on their ISP.

Despite all of the messages, I don't see any disagreement on 
this.  Really, folks, if someone wants to build a software 
package that can be configured either to be a conforming SMTP 
MTA or an X.400 P1 transport agent, we couldn't prevent that if 
we wanted to, nor should we want to.  Similarly, if something 
can be configured to do MX resolution as specified in 821bis or 
to select a likely relay host by walking the DNS in random order
looking for WKS records specifying SMTP and picking the first 
one found, we can't prohibit the behavior.  

We can (and arguably should if we conclude that it would be 
important enough) explain why doing such a thing would be dumb. 
And we need to decide whether the second option is conforming, 
if chosen.  If we conclude it is, then the text ought to say 
something like "SMTP senders SHOULD use MX resolution, but MAY 
chose to walk the tree and... instead".  If we conclude that it 
is not, then the text should say something more like "SMTP 
senders MUST use MX resolution...".    And, if we really don't 
care how it resolves names, we could say "SMTP senders MAY 
determine addresses for the next hop by MX resolution, or by...,
or by...".

In neither of the first two cases are we preventing the code from
being there -- only good sense and the market can determine 
whether it will be or not.  The only decisions we get to make 
are

  -- whether something configured that way is, or is not, 
     describable as a "fully (or partially) conformant 821bis 
     system" by an informed and reasonable party acting in good 
     faith.

  -- whether to _define_ "SMTP system" and/or "SMTP MTA" and/or 
     "Internet mail MTA" as equivalent to "821bis system" in 
     statements about conformity.  Note that this is a matter of
     definition, not morals or divine right.

Any chance we can stop kicking this particular dead horse?

       john

---

From: Ofer Inbar <[email-masked]>
Date: Wed, 17 Feb 1999 16:10:51 -0500 (EST)

> that software is RFC 821 compliant.  End of story.

Even with "as if", MX is still an issue.

If I connect to an SMTP port and speak SMTP to it to send mail, and I say:
RCPT To:<[email-masked]>

And there's an MX record in the DNS that says "hostblah MX 10 hostbleep",
I expect the email message I just typed to be delivered to hostbleep.
If it instead gets delivered to hostblah, I would consider the server
I just talked to to not be an SMTP compliant server.

  --  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: "D. J. Bernstein" <[email-masked]>
Date: 17 Feb 1999 22:19:27 -0000

A few hosts know how to deliver messages to addresses @cs.brandeis.edu.

The general rule for other hosts is to move each message _closer_ to
cs.brandeis.edu. This can be done in many different ways. Examples:

   * The client transfers the message by SMTP to a lower-distance host
     in the MX list for cs.brandeis.edu.

   * The client transfers the message by SMTP to its ISP's mail relay.

   * The client transfers the message by UUCP to its ISP's mail relay.

Mail relays will be an essential part of Internet mail until every host
is connected 24x7. The current 821bis draft is simply out of touch with
the reality of how mail relays are used.

> I just talked to to not be an SMTP compliant server.

If that host relays outgoing mail through its ISP's mail relay, which
happens to be hostblah, then it is successfully moving the mail closer
to the target.

---Dan

---

From: Pete Resnick <[email-masked]>
Date: Wed, 17 Feb 1999 16:39:37 -0600

>    * The client transfers the message by UUCP to its ISP's mail relay.

Irrelavent. Not SMTP. Has nothing to do with conformance to 821(bis).
>    * The client transfers the message by SMTP to its ISP's mail relay.

Good. Seems like a reason to have a SHOULD; it's a "valid reasons in 
particular circumstances to ignore" using the MX rule.

>      in the MX list for cs.brandeis.edu.

Broken behavior that I've seen in practice. A bunch of clients got 
deployed that ignored the MX rule and attempted delivery to only the 
highest number of three availabe MXs instead of the lowest number. 
The highest number was a last resort machine that did a bunch of 
other stuff. The clients flooded the last resort machine; denial of 
service resulted.

The rule is (a) "go to the lowest MX you can get to". The rule isn't 
(b) "get it closer". Every implementation I can think of either 
follows (a) or ignores it and sends to a designated mail relay for 
mostly good reasons. I've never heard of anyone implementing (b) 
except for the above mentioned client, and it was a disaster.

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

---

From: "D. J. Bernstein" <[email-masked]>
Date: 17 Feb 1999 23:32:22 -0000

Pete Resnick writes:
> The rule is (a) "go to the lowest MX you can get to".

Yes, clients try the MX records in order. But ``try'' does not mean what
you think it means.

For example, if the lowest-distance IP address has failed several times
recently, modern MTAs will skip it, and go on to the next host. This is
a popular, widespread, beneficial feature.

I agree that high-quality mailers will, under most circumstances, start
with a TCP connection to the lowest-distance host. But the situation is
not as simple as you seem to believe.

> other stuff. The clients flooded the last resort machine; denial of 

Specious argument. The last-resort machine is normally going to receive
_all_ the mail if the other machines are unreachable. It shouldn't have
been in the MX list if it couldn't handle the job.

  [ UUCP to the ISP's mail relay ]
> Irrelavent. Not SMTP. Has nothing to do with conformance to 821(bis).

Ah. So UUCP is allowed, but SMTP is prohibited in the same situation?

Some people have been suggesting that the server has to make an SMTP
connection as per the MX records. Using a different protocol, or
connecting to a different host, violates this requirement, but is an
essential element of Internet mail today.

---Dan

---

From: Ofer Inbar <[email-masked]>
Date: Thu, 18 Feb 1999 18:40:53 -0500 (EST)

> happens to be hostblah, then it is successfully moving the mail closer

If.

However, given that there's no MX record of any sort pointing to
hostblah, there's no way to know whether or not moving the mail there
will get it closer or not.  It might result in the mail being lost, or
being processed in some other way, or being delivered to the wrong
place.  In the absence of an explicit agreement between the SMTP
server in question and the admin of hostblah, the SMTP server which
does this is in violation of the standard and potentially dangerous.

Now, nothing you have said on this list so far leads me to believe
that you disagree with the above paragraph, so I'm not trying to argue
with you.  Here's the point I was trying to make:

People were discussing rules for how an SMTP server decides where to
send mail to.  Some people believed these rules should be separate
from the SMTP protocol.  One person brought up the "as if" rule to
justify this position - as long as an SMTP server behaves "as if" it
followed the protocol, then it is compliant, and thus, these rules
about MX shouldn't be part of the protocol.

My contention is that the "as if" principle does *not* imply this.
An SMTP server which uses different rules for decided where to send
mail that are specified in the protocol, gives results that are not
what a user would expect, and hence is in violation of the protocol.

Hence, my point is this:  Rules about how an SMTP server decides where
to relay mail to, are legitimately part of the SMTP protocol and
belong in the document.

I have made no statement about WHAT I believe those rules should be.

I'll make a tentative one now, though.  Roughly speaking, the rules
should say that the decision may be based either on an explicit
agreement between specific servers (or clients and servers) and thus
configured by their respective admins, OR the decision must be made
using MX (or SRV) records from DNS.  No other method should be allowed.

I think it is important to state that in the document.

  --  Cos (Ofer Inbar)         -- [email-masked] [email-masked]
  --  The Left Bank Operation  -- [email-masked] http://www.leftbank.com/
  "A distributed system is one in which I cannot get any work done
   because a machine I've never heard of is down" -- Leslie Lamport

---

From: Ofer Inbar <[email-masked]>
Date: Thu, 18 Feb 1999 18:54:15 -0500 (EST)

Philip Hazel <[email-masked]> writes:
> On Wed, 17 Feb 1999, Ofer Inbar wrote:
> 
> Surely you cannot expect this unless you know something about the host 
> whose SMTP port you have connected to? Or are you using "SMTP" in the 
> strict sense that 821bis seems to demand, not just as a name for port 25?

Good point.  Let me clarify.

Say I am helping out a friend, and my friend has an ISP.  Her ISP gave
her a setup tip sheet of some sort that says "Our SMTP server is
mailhost.isp.com", in the section about configuring her mail software.

Based on that assertion, I should be able to expect the above behavior
from whatever is running on port 25 on mailhost.smtp.com.  It may
actually relay first to some central server in the ISP's network, I
don't care about that.  However, the mail I send MUST eventually be
delivered to hostbleep and NOT hostblah.  If it is delivered to
hostblah (which has no MX records pointing to it), I would like to be
able to complain to the ISP, and point them at the SMTP RFC.  If mail
submitted to mailhost.smtp.com via SMTP protocol does not end up being
delivered according to MX rules, they should not be telling people
that it is their "SMTP server" - it is a violation of the protocol.

If the target hosts hostbleep and hostblah are actually within ISP's
own administrative domain, then they can do whatever they want, of
course.  But let's pretend that those two hosts are actually mine, and
that I have made no explicit agreement with ISP as to how mail should
be delivered to my hosts.  I want to be able to rely on MX behavior
from anything that is labelled an "SMTP server" to third parties (in
this case, to the ISP's clients, who are "third parties").

  --  Cos (Ofer Inbar)         -- [email-masked] [email-masked]
  --  The Left Bank Operation  -- [email-masked] http://www.leftbank.com/
  "We're getting at least 50% packet loss all over the place...  if not
   for the fact that our ISP is SO incompetent that they even forget to
   bill us, i'd switch..."     -- (anonymous by request)

---

From: "D. J. Bernstein" <[email-masked]>
Date: 19 Feb 1999 07:43:54 -0000

How about this: A client MUST NOT attempt to send mail to a server
without authorization. There are several common forms of authorization:

   * ``domain MX server'' in DNS constitutes public authorization to
     send mail for that domain to that server. (It is the responsibility
     of the domain owner to obtain permission from the server owner
     before setting up DNS records mentioning that server.)

   * ``domain A server'' in DNS constitutes public authorization to send
     mail for that domain to that host _if_ there are no MX records for
     the domain.

   * A typical Internet service provider sets up one or more servers and
     informs its customers that they may use those servers to relay
     outgoing mail to any domain.

This is not an exclusive list.

Ofer Inbar writes:
> Some people believed these rules should be separate
> from the SMTP protocol.

Modularity is a good thing. SMTP is used in many contexts other than TCP
connections to MX->A port 25; Klensin's draft makes it unnecessarily
difficult to describe those contexts. This is not a new observation.

> One person brought up the "as if" rule to justify this position

No. That was a response to ``clients aren't required to use MX records
but have to know how.'' (Paraphrased.)

---Dan

---

From: Philip Hazel <[email-masked]>
Date: Thu, 18 Feb 1999 10:11:04 +0000 (BST)

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

---

From: Philip Hazel <[email-masked]>
Date: Fri, 19 Feb 1999 10:00:40 +0000 (BST)

On 19 Feb 1999, D. J. Bernstein wrote:

> without authorization.

I think this is a useful statement.

> Modularity is a good thing.

I entirely agree.

> SMTP is used in many contexts other than TCP
> connections to MX->A port 25;

Quite. And people will continue to call such uses "SMTP".

---

From: [email-masked] (Kai Henningsen)
Date: 20 Feb 1999 13:55:00 +0200

> This is not an exclusive list.

I like this language.

MfG Kai

---

From: Russ Allbery <[email-masked]>
Date: 23 Feb 1999 16:38:29 -0800

Kai Henningsen <[email-masked]> writes:
> [email-masked] (D. J. Bernstein)  wrote on 19.02.99:

> I like this language.

So do I.  I personally wouldn't be surprised to see things go *more* in
the direction of using relays rather than delivering directly, given the
increased number of firewalls and firewall-like port blocking done for
spam and security reasons, and it makes sense to me to include language
like the above to allow for those cases.

The Internet isn't necessarily synonymous with "direct relay," just like
it's not necessarily synonymous with "default-free."