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

From: "Larry Osterman (Exchange)" <[email-masked]>
Date: Mon, 15 Feb 1999 18:32:38 -0800

I think the real issue is not CONFIGURATION but CAPABILITIES.  As long as
the software that is deployed in the LAN scenario below is CAPABLE of doing
full MX resolution, I don't believe ANYONE would have a problem with saying
that it is compliant.

This has in fact been one of the things that Dan has had difficulty
understanding.  The issue w.r.t. this standard is the CAPABILITIES of a
piece of deployed software, not the CONFIGURATION of that software.  Dan
keeps on throwing up valid configurations as straw men to show why there is
a problem with the spec, and everyone else keeps talking about the abilities
of the software (his interminable discussion about the protocol require that
a server respond to a QUIT even after the power is turned off is a good
example of this).  As a result, everyone ends up shouting at everyone else
and the only result is raised blood pressure all around.

As far as DRUMS is concerned, it should define the standard for how
correctly functioning internet MTAs should function.  However there is no
reason for a site CHOOSING to deploy something that isn't 100% per spec.  In
the case below, I think this is a clear case of why 2119 defines SHOULD in
the way it does (yes, I know that 821bis doesn't follow 2119, but the
terminology is relevant).  In this case, the site has a very good reason for
choosing to ignore a portion of the specification.  

I also agree with the "relays and destination MUST and originators SHOULD"
language, although I suspect that even the latter SHOULD may be too strong
for a certain class of submission devices (I don't want my cellular phone to
have to be able to do MX resolution).

Larry Osterman
Sent from larryo-laptop.dns.microsoft.com running NT5 and Outlook 2000
and Exchange Server 5.5.  Please notify the sender of any difficulties

-----Original Message-----
From: Jeff Stephenson (Exchange) 
Sent: Monday, February 15, 1999 4:37 PM
To: [email-masked]
Subject: RE: editing status of 821bis, draft -10.

> -----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: "D. J. Bernstein" <[email-masked]>
Date: 16 Feb 1999 12:29:39 -0000

Larry Osterman (Exchange) writes:
> The issue w.r.t. this standard is the CAPABILITIES of a
> piece of deployed software, not the CONFIGURATION of that software.

If a user wants to send all messages through a single host, he doesn't
need an SMTP client that knows how to look up MX records. There is no
interoperability issue here.

Some companies prohibit internal use of DNS for security reasons. They
don't _want_ an SMTP client that knows how to look up MX records.

There is no reason for these people to install MX resolution code. It is
a barrier to competition, in violation of antitrust law, for a standards
organization to ask them to pay for features that aren't enabled. In the
FTC's words, standards must not impose ``construction requirements'' in
place of ``performance requirements.''

> understanding.

The picture here is crystal clear. You are trying to declare that small,
inexpensive, special-purpose SMTP implementations are ``non-compliant,''
even though there is no interoperability excuse for doing so.

---Dan

---

From: Russ Allbery <[email-masked]>
Date: 16 Feb 1999 10:13:52 -0800

Larry Osterman (Exchange) <[email-masked]> writes:

> I think the real issue is not CONFIGURATION but CAPABILITIES.  As long
> as the software that is deployed in the LAN scenario below is CAPABLE of
> doing full MX resolution, I don't believe ANYONE would have a problem
> with saying that it is compliant.

> This has in fact been one of the things that Dan has had difficulty

No, this is a straw man that really has little to do with the argument,
except for those sections dealing with crash behavior.  Configuration
vs. capabilities is not a useful distinction for supported features (as
opposed to error recovery).  If a site wishes to not install a given
capability, it's stupid for them to leave it in the software where it can
get turned on by accident, cause security holes, bloat the application,
and in other ways stick around as dead code.  The obvious thing to do is
to install software that doesn't have the capabilities they don't want.

> The issue w.r.t. this standard is the CAPABILITIES of a piece of
> deployed software, not the CONFIGURATION of that software.  Dan keeps on
> throwing up valid configurations as straw men to show why there is a
> problem with the spec,

Dan has also been pointing out that there is software which cannot even be
*configured* to have that capability because the target audience for the
software doesn't *want* that capability, so including it just means more
code to try to make secure for no gain.  In that, he has a perfectly valid
point.

However,

> correctly functioning internet MTAs should function.

I largely agree with you here.  But I think the SHOULD/MUST distinction
should be applied where possible so that applications of SMTP which aren't
standard Internet mail aren't excluded needlessly from the standard.  I
think most of us agree there.

> In the case below, I think this is a clear case of why 2119 defines
> SHOULD in the way it does (yes, I know that 821bis doesn't follow 2119,
> but the terminology is relevant).  In this case, the site has a very
> good reason for choosing to ignore a portion of the specification.

Agreed.

> I also agree with the "relays and destination MUST and originators
> SHOULD" language, although I suspect that even the latter SHOULD may be
> too strong for a certain class of submission devices (I don't want my
> cellular phone to have to be able to do MX resolution).

Under that language, internal relays may be violating the "MUST" with good
cause.  But I don't have a fix for that either, and in practice I don't
think it's likely to be that important.

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

---

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

On Tue, Feb 16, 1999, Russ Allbery <[email-masked]> wrote:

>                                              The obvious thing to do is

    I disagree.  Do the permutations and combinations of every possible
feature that could possibly be turned on or off, and you'll quickly
realize that it's simply not feasible to write software this way.  It's
one thing in the physical world where more sheet metal to make a certain
feature costs money and the labour to shape it, but in the electronic
world it actually costs more money and labour to rip out certain features
that others want/need.

    Granted, you have to strike a balance.  For example, a firewall
machine shouldn't have a C compiler, Perl, or any other sort of toolkit
that would make it much easier for a hacker to use that machine as a
jumping off point to attack the whole rest of your network, once it is
compromised.  It should be isolated enough (and the rest of your network
security should be good enough) that they don't gain a whole lot by
breaking into your firewall.

-- 
  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:24:06 -0800

>> The obvious thing to do is to install software that doesn't have the
>> capabilities they don't want.

> world it actually costs more money and labour to rip out certain
> features that others want/need.

I think this is probably the wrong forum to argue fundamental principles
of system administration and software design.  I'll just say this and let
it rest there:  Creeping *useless* featurism in software products, rather
than flexible capabilities that can be removed when they are not
necessary, is the single biggest crime of this industry.  It results in
bloated, useless, wasteful software with excessively complicated
interfaces to support thousands of features that the average user is never
going to touch.

And, specifically in anything that talks to untrusted hosts, it's not only
useless, it's *dangerous*.  Security holes are proportional to lines of
code.  It almost doesn't matter what the code does.  It's absolutely
criminal to load down software with more and more complicated handling of
data that can break in more and subtler ways rather than finding the
appropriate decomposition for the problem.

The role the standardization process holds in this is the responsibility
to carefully consider what capabilities are made mandatory and to not
require functionality that's not *directly* related to and *required* for
correct interoperability.  And to design the protocols for
interoperability in a way that minimizes the amount of complexity that has
to be required.

Certainly, MX lookups are basic interoperability and are a requirement for
any software package that routes Internet mail (as possibly distinct from
a software package that delivers mail via SMTP).  But the general
principle is still important.

And this is rather far from the impossibility that you portray it as.  I
select software on this basis all the time.  When I'm looking for software
to run a production server, I specifically look for software that is
attempting to do one thing and well, not be all things to all people.  And
pity the people who install kitchen sinks that are too large for any one
person to understand when that isn't necessary for the service.  And
generally I can find what I want.

The software market is large.  There doesn't have to be one MTA.  There
doesn't have to be one ftp server.  It's actually possible to cater to
different markets, and that doesn't mean putting in more features than
your competitor.  We have specialization and division of labor for a
reason.