ietf-822
[Top] [All Lists]

Re: on the end-to-endness of SMTP

1991-06-10 18:35:27
This is exactly the problem with the current model.  SMTP *is* an
end-to-end system.

Says who? SMTP explicitly allows for source routing in addresses. This is 
not something tacked on as an afterthought -- it is a well documented and
heavily used aspect of the protocol. The host requirements RFCs have
confirmed the status of routing in SMTP.

Says me, says Host Requirements, says the IETF.  In host requirements
we depricated source routing just for this purpose.  I know, I was
there when we did it.  Understand that this is not a routing argument,
but an argument about whether SMTP is end-to-end.  The two are
necessarily related.  Here are some of the relevant passages, to
refresh your memory:

(quotes from RFC1123 deleted)

Thanks for supporting my argument so nicely. Nothing, not a particle, of
what you quoted says that an SMTP agent can blow off source routes. It
"should not" generate them. It must support them. It must honor them.

The simple fact that the host requirements RFC was unable to disparage
souce routing to the point where it became optional was precisely what I
was referring to. Nothing more, nothing less.

You can see the authors of the thing very clearly -- a bunch of people who
don't like routing but are unable to get rid of it completely. Reality
sets in (grin).

I did not want to drag all this onto the list, but if I must, I must. The
host requirements RFC is hopelessly unrealistic in this area. It disparages
routing without providing mechanisms to avoid the need for routing. Until
mechanisms are supplied that eliminate the need, routing will continue to
be used, either formally using source routes or informally using percent
hacks.

I can start enumerating the needs for routing if you like, but this is
hopelessly off the subject.

The solution to this problem is to eliminate the need for routing. Until you
do this you will have routing whether you (or I) like it or not.

I hate routing. I'm a strong advocate of using alternatives wherever they
exist, and I also advocate the development of alternatives where they don't
exist.

As an aside, I also happen to feel that the host requirements implicit
endorsement of percent hack routing is one of the most gutless things I've
ever seen. Rather than solve problems, or acknowledge they exist, the
"preferred" solution is to sweep it all under the rug, where presumably
it may go away, or at least we don't have to look at it. This is not a
useful position to take.

This means that right now, if a site accepts
delivery for a message, it has the means under normal circumstances to
deliver it - in essense offering that gaurantee.

Not true. The PP mailing list had a huge debate on this issue some time 
back -- I suggest you check the archives for that list if you're really 
interested.

Sir, I've been in more arguments about this issue than I care to.  The
PP people have had their arguments, I'm sure.  But this is an
important point, because I believe it is one of the features that has
kept our mail system as clean as it is.  So if you want to rehash it
with me, let's.

We can certainly do this if you want to, but off the list, if you don't
mind. But you can argue until you're blue and not change current practice.
I've been building my examples out of current practices. I rarely have to
make up examples -- the real world is such a rich source.

[yet another example of how to screw up a mail system; expunged]

I think we agree that it is important to keep 8 bit mail from 7 bit
MUAs.  We can do that by using lookaheads and by agreeing that this is
an SMTP standard.  Keeping SMTP end to end is the simplest way to keep
the hair of unnecessary complexity off of our systems.

Oh God, NO! Lookaheads are simply a terrible idea. I would much rather
invest 1000 times the authority we currently give MTA than use lookaheads.

Adding lookaheads affects MTAs in a very critical place -- routing. Most
MTAs don't have a good grasp of routing, or the timliness of routing
information, as it stands. I really think that adding complexity to the
name resolution/lookup in an MTA is a very bad idea.

Adding a converter, on the other hand, is pretty simple. You check to
see what sort of message you're processing and set a flag. The
SMTP agent then uses the proper set of commands. If an extended command
fails the agent clears the flag and calls the convert routine for the
current message. This is very easy to implement. The added complexity is
in a separate module that says separate.

The converter has to be correctly written. But since it is a black box as
far as the MTA is concerned it only has to be correctly written once.
Retrofitting lookahead strategies has to be done over and over and over again,
with potentially disasterous results.

This is not to say that conversions won't be necessary; just that your
average agent shouldn't need them.  You may need to do conversions if
you explode mail for mailing lists or for user forwarding.  This is
not an SMTP matter, however.  It would occur essentially where final
delivery would otherwise occur.  How that happens should be
recommended, but it is essentially an implementation detail once an
acceptable conversion format is agreed to.

Sigh. I never said that the average agent should need them conversions. I
said that refusing the right to convert to MTAs is not an acceptable
position. You have yet to demonstrate that this assessment is incorrect.

More and more we are seeing ``mailing list processors'' handle mailing
lists.  There's even an IETF working group of which I bet few if any
of you are probably aware.  The function of such a list processor may

Well, *I* was aware of the working group. I don't see how list processors have 
much to do with message content conversion, but if you want to make
a case for it, go right ahead.

This leaves the case of forwarding mail to another site, and it can be
handled with a conversion utility, which presumably will be available
in the long term, when 8 bit smtp is to be implemented.

Fine. Let's allow the inclusion of this utility in an MTA.

                                        Ned

<Prev in Thread] Current Thread [Next in Thread>