From: Ofer Inbar <cos@leftbank.com>
Message-Id: <199701221938.OAA00460@zax.leftbank.com>
Subject: Re: header registry & layering
To: drums@cs.utk.edu
Date: Wed, 22 Jan 1997 14:38:38 -0500 (EST)
In-Reply-To: <Pine.SGI.3.95.970120112719.23132W-100000@shellx.best.com> from "Gregory J. Woodhouse" at Jan 20, 97 11:46:09 am
Organization: The Left Bank Operation - http://www.leftbank.com/
Reply-To: cos@leftbank.com
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

> It seems to me that the only practical approach to thix problem is to
> conceptually partition the header into three sections: one which can be
> examined and modified (including additions) by MTAs, one that can be
> examained but no modified by MTAs, and one which is forbidden to MTAs
> altogether. Of course, there will be no protocol enforced separation,
> rather the separation will have to be spelled out in the standards.

That sounds like a horrible mess, and I think that is describes
exactly the situation we're trying to avoid.  The more the envelope
creeps into the header, the more we have to define how MTAs deal with
each header field.  I think we'd prefer not to have to do that.

I don't really care what header fields and MTA "looks at", depending
on your definition of looking.  What I really want to avoid is:
 - MTAs modifying header lines.
  (They can add new ones, that's not the same thing.)
 - MTAs being forced to understand the content of header fields in
   order to carry out their protocol-defined duties.

> >  - Information that must be interpreted by MTAs in order to properly
> > do their job, should be kept out of the header as much as possible.
> >    Received: doesn't violate this, except where MTAs count Received:
> > lines, but I don't believe that counts as "information that must be
> > interpreted by the MTA to properly do its job".
> 
> Why not? Because the MTAs don't have to look at their values? What if
> instead of having Received: headers we had a single Hop-count: that wass
> incremented by each MTA? Would your comment still apply? (Note that I don't
> mean to suggest this is a good or bad idea. It's just an example.)

My comment applies in either case, because the SMTP protocol does not
require MTAs to calculate the hop count (either by counting Received:
lines, or by reading a Hop-count: header, it doesn't matter).  An MTA
can fulfill its SMTP duties without ever looking at these headers.

There are some very good arguments against hop-counting.  To get on a
short tangent here, loop detection in email is a complex enough issue
that it should be dealt with separately, and possibly result in a
separate standards-track RFC.  It may be that this standard ends up
defining a header field that MTAs have to read, and that would be a
real exception to what I stated above.  Which brings us to...

> >  - Exceptions to the above may be good in some rare cases, but these
> > should be evaluated separately.  Something like X-Loop may or may not
> > be such an exception - I don't know enough about it.  But if such an
> > exception were to be made, it should go through standards track process.
> 
> I agree.

  --  Cos (Ofer Inbar)  --  cos@leftbank.com  cos@cs.brandeis.edu
  --  WBRS (100.1 FM)   --  WBRS@brandeis.edu http://www.wbrs.org/
  "Isn't it a shame, that someone so crazy could go so insane?"
     -- The Nields, "James"