[Top] [All Lists]

Re: How to handle a lot of character set Content-types

1991-05-08 05:15:11
Stef writes, as part of a message that I found very helpful...

Now, where I think John and I might disagree, is that I believe that
RFC821/822 come incredibly close in their parallels to X.400 P1/P2 as
abstract functional service definitions.

As I am beginning to think is usual, we don't disagree by much.  In 
retrospect at least, my comments in that direction were based on four
  (1) The RFC821/MTA function tampers with the "message format" headers, 
at least to the extent of stuffing in Received fields at relays.  IMHO, 
in a clearly separated MTA/UA model, it would stamp these on the bakc of 
the envelope somehow.  As a corollary, there has been a great deal of 
discussion in the RFC-XXXX context about non-gateway MTAs looking at,
evaluating, and tampering with headers and message content.  I suggest 
that, in the presence of a strong separation model and general 
understanding of, and agreement about, it, much of that discussion would 
be ruled out of order as obscene and an offense to public morality :-).  
But, as I am sure you and I (at least) agree, that is precisely why 
discussion and consideration of the character of the abstract models we 
are trying to work from is critically important.

  (2) The fact that I see the local-UA -> remote-MTA operational form as 
introducing behavior changes that intrude on the model, especially if it 
is combined with a local MTA in a "try UA -> remote-MTA once, then spool 
to local MTA" implementation.  We agree that, if this is done perfectly 
and transparently, it is a local problem that makes no different.  
However, to cite one--necessarily trivial--example, the local MTA in 
many of those implementations is treated as a relay, such the that 
operation becomes
   (try once):   originating-UA -> remote-MTA
   (then):  originating-UA -> relay-MTA -> remote-MTA
where the relay-MTA just happens to be local to the originator.  These 
two models produce different Received fields in the delivered message, 
and I suggest that is an externally-visible (and therefore protocol- 
visible) difference, however trivial.

  (3) My more complex layering is an attempt to create an abstract model 
of mail implementations, rather than of mail transport and delivery.  
Those two sets of models are consistent but serve slightly different 
purposes, so no disagreement there.

  (4) Finally, I was backing into what you so precisely and eloquently 
stated as 
and its unfortunate, but equally false relative
Regardless of the inherent qualities and virtues of sendmail, it is 
altogether too easy to configure it in ways that make that statement 
false.  Indeed, there seems to be a thriving cottage industry in such 
unfortunate configurations.  :-)

I learned a lot from other things in your note.  Thanks.