Re: preventing header tag spoofing without crypto

On Mon, Mar 29, 2004 at 09:42:27PM -0600, David Nicol wrote:
> in my experience, RFC2822 tags are shuffled around and added if
> nonexistent, unrecognized tags are left alone.  We are contemplating
> introducing a new standard tag, and we may declare that its ordering
> is to be left alone as part of its specification.  Systems that do
> rearrange it will be out of compliance.  They will also be on the
> far side of our compliant systems.  By leaving everything in order
> it is simple and clear, the top of the headers is near and as we
> get farther into the headers we are reading something farther and 
> farther away.  Story headers get added at the top, just like
> geologic strata. :^)

I am not in favor of mandating specific order in filter-generated
headers.  I go back to what Laird said:

   If ordering is important, a better system consists in embedding a
   counter which can be sorted on by anybody who needs to see headers
   in chronological order.

and wholeheartedly agree.  Earlier we talked about an 'id' field that
could be used to relate the formally-defined headers produced by a
particular filter at a particular processing point.  (i.e., as a
'join' field) An 'id' that is simply numererically greater than any id
seen in existing headers would do the trick.  Date/time information
could be (and should be, IMHO) treated as additional, probably tagged,
information-- and we could either spec that out as optional or
required.

mm