Re: filtering header draft rev 35

On Jun 27 2004, david nicol wrote:

> Looks good.  I want to make a whole pile of grammar and word choice
> edits, changing "last" to "latest" and swapping passive voice for
> active.

Great. I'm not claiming my edits are polished in any way.

> 
> I continue to think that rewriting a tag you are replacing is the
> way to go, because it is less confusing to stupid legacy software.

I don't see why this needs to be an either or choice. In my mind,
I see a variety of similar headers, and any reader can pick and choose
the relevant ones. There's no limit for the number of headers in the
header section, and mostly it's software that will read them anyway.

> 
> I have been imagining that such a tag would get rewritten to something like:
> 
>     Old-Tag-Helo-example.net-Peerip-1.2.3.4: result=Good [... 
> authentication and identity stuff ...]
> 

It seems to me what you really want is to ensure that the final header
line format is easily parseable via some regular expression, no? We should
be able to accomodate that without too much trouble. 

However, I'm not too happy with the example above for now, it needs to be
thought out some more. What if you don't have a DNS name, only an
IP. Or what if you can't resolve the IP when writing? You'll have
a lot of different looking headers, which is what we want to avoid, right?

Something along the following lines is what I had in mind up to now:

 Processed: function=rewrite-Helo; location=1.2.3.4; result-tag=good;
       name=Helo-checker; auth-received= ...
 Processed: function=spamcheck; location=4.5.6.7; result-tag=spam; 
       name=SpamAssassin; confidence=89; ...

It's a bit verbose, but it's regular enough for easy parsing, and you
only parse available information (ie there's no holes where missing
information should be).

Does that make sense or are we talking about different things?

> for MUA filing rule simplicity.

> Maybe, keeping them intact all the time,  we can have legacy filing 
> rules look at more than
> the result part without having to match pieces from one header with 
> pieces from another.  The

There's no obligation to authenticate any headers some software wants
to read, it's just an awfully bad idea unless the consequences are
100% understood. 

Legacy MUAs won't authenticate, but in fact it would be possible to
have a standalone filter whose sole purpose is to read headers and
remove those which can't be authenticated, while making sure the 
remaining ones are properly formatted for the new standard.

-- 
Laird Breyer.