Re: filtering header draft rev 35

Laird Breyer wrote:

>FYI The miller-et-al filter header document is now at revision 35,
>and includes a few more sections. 
>
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.

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.  And I think the method 
for arriving at
what the name of the rewritten headers is should identify who rewrote 
them, because
that makes it possible, for instance, to respect a tag placed by a 
mailing list and renamed by
my e-mail box service, while ignoring the same tag forged by a sneaky 
advertiser, using
current MUA software.

So,  a mailing list ([email protected]) runs CRM114 on its mailing list 
and shares the
resulting categorizations with our header:

    Tag: result=Good [... authentication and identity stuff ...]

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 ...]

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
down side to not reccommending rewriting is MUAs that do not know about 
these new hoops to
jump through are vulnerable to header forgery.

A MTA that rewrites any Tag: header it sees, as shown above, with the 
peer IP and [he]{2}lo
name where the tag came from, and possibly rewrites Old-Tag-... in the 
same way, giving
Received: line tracing for each Tag to the left of the colon -- forgery 
would not be
possible.

I am in favor of rewriting the name of old tags.