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

From: "Larry Osterman (Exchange)" <[email-masked]>
Date: Tue, 16 Feb 1999 10:19:49 -0800

I probably shouldn't do this, but I'm going to anyway......  Here goes....

Please note that I'm ONLY talking about the MTA scenario here.  I'm already
on record as stating that requiring MX resolution when SMTP is used as a
submission protocol is too strong a requirement (SHOULD is probably
sufficient however).

There are two cases here:
	1) The user acquires (by whatever means, either purchasing it (PMDF,
Lotus, Sendmail, whatever) or by downloading freeware (Qmail, etc)) an MTA
that is advertised to be RFC821bis compliant.
	2) The user writes an MTA and wants it to be 821bis compliant.

In the first case, the claim is that the author of the software must put MX
address resolution in the software package.  They don't have to enable it in
every case, but they MUST provide the capability of doing MX address
resolution.  Similarly, there is no reason for the user to DEPLOY this
ability, as you mentioned, they may have site criteria that require an
alternative mechanism of resolving host names (via hard coded host files, or
whatever, it's not important).  There is no way that the IMPLEMENTATION
could be considered to be non conformant, even if one of its deployment
scenarios doesn't include MX resolution.  All of the strawmen regarding ISP
scenarios that Dan has put forward fall into this category - the ISP's MTA
must be capable of doing MX resolution (since it's the one talking on the
internet), but the user's MTA (which only talks to the ISP's MTA) doesn't,
it can talk to a fixed IP address for all it cares about.

In the second case, as long as it never hits the internet, it's not relevant
if the software does MX resolution or not.  It's a proprietary piece of
software and it can implement whatever it wants.  It doesn't even have to
talk SMTP or use port 25, or whatever.  But the instance that this software
starts acting as an internet MTA, it had better play by the rules, and the
rules state that email routing is done via MX record resolution.  And if the
user's MTA already does everything else in MSTP right, the cost of adding MX
resolution to the existing software is relatively minor.  

Like it or not, in the internet email sandbox everyone has to play by the
same rules.  At one time the rules were hard coded routing tables and
store-and-forward.  Now the rules require that MTAs use MX resolution to
route to the destination host.  

And yes, I know that some implementations don't do such a good job of
playing by the rules, again, that's not relevant to this discussion - we're
trying to decide the set of rules that will make internet email more healthy
than it currently is.  And clearly stating the requirements of the protocol
at all levels is a START at moving in that direction.  It means that if
someone DOES try to put an MTA out on the internet that only does A record
resolution and not MX record resolution that others can say to the offender
"Hey - you aren't following the rules, and you will cause damage by
continuing to do what you are doing".  If we don't clearly specify the
requirements of an SMTP server @i(on the internet), then we will have been
derelict in our duty to improve the internet email situation....

Anyway, that's more than I wanted to write, but....

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: D. J. Bernstein [mailto:[email-masked]]
Sent: Tuesday, February 16, 1999 4:30 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: editing status of 821bis, draft -10.

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

> This has in fact been one of the things that Dan has had difficulty
> 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: "D. J. Bernstein" <[email-masked]>
Date: 16 Feb 1999 23:17:07 -0000

My maildirsmtp program sends messages by SMTP from a local queue to an
address specified by the user. It's part of my serialmail package, used
by many ISPs to transmit mail to dialup hosts, and used by many dialup
hosts to transmit mail to ISPs. serialmail doesn't know anything about
MX records.

Larry Osterman (Exchange) writes:
> the author of the software must put MX
> address resolution in the software package.

So, if that requirement is part of the SMTP spec (against federal law),
then maildirsmtp is violating the SMTP spec---but you say it's no longer
violating the spec if I integrate it into the qmail package?

What if it's available as part of the qmail package, but _also_
available separately? Is the second copy violating the SMTP spec while
the first copy is complying with the SMTP spec?

What if it's still shipped separately, but requires that you install
qmail first? Does that still violate the SMTP spec?

What if it's shipped as part of the qmail package, but the installation
process lets the user discard programs that he isn't using? Does that
violate the SMTP spec?

What if maildirsmtp and qmail are both shipped as part of the system,
and each one can be installed with a single command? Does that violate
the SMTP spec because maildirsmtp can be installed without qmail? What
if qmail is installed from a CD? How about a remote CD? Floppies? What
if the qmail floppy is sold separately from the maildirsmtp floppy?

> (SHOULD is probably sufficient however).

Changing MUST to SHOULD doesn't fix a stupid requirement.

---Dan

---

From: [email-masked] (Kai Henningsen)
Date: 18 Feb 1999 09:37:00 +0200

> submission protocol is too strong a requirement (SHOULD is probably

There are three situations:

A. Standard Internet SMTP MTA, in it's role as such. MUST do all the MX  
etc. stuff.

B. Smarthost-using SMTP client. MUST have some sort of (possibly indirect)  
agreement with the smarthost. *If* mail out of the smarthost - or the  
smarthost's smarthost - enters the Internet, it MUST be handled via A.  
Need not do MX and friends.

C. SMTP server with local configuration. MUST have some sort of (possibly  
indirect) agreement with all the mail destinations delivered via these  
local rules. Need not do MX and friends.

Now, a "real" MTA will often be a combination of all three cases, and a  
MUA will often be B (and people will even insist on it being type B and  
not do MX).

Furthermore, it is not clear how much of the above is actually fit for  
821bis.

But I think this is approximately what we want to have. Now to find  
suitable language ...

MfG Kai