preventing header tag spoofing without crypto

This is a sort of generalization of a point made by David Nicol, which
I think is quite intriguing, and I'd like to offer up for discussion. 

The problem: 

Filter A adds a header tag T, later filter B reads the header and must
decide if tag T is a tag truly added by A, or if T is a spoofed tag
added by spammers much, much earlier.

Some approaches proposed by various people here: 

Filter A always overwrites tag T, and filter B is told that filter A 
always looks at the incoming message first. This way, B always trusts T.

Filter A includes in T an authentication based on a secret password.  
Filter B looks for the secret password, and trusts T if the password
checks out. This way, both filters must be kept in sync re password management.

A new approach:

(If I understand it correctly)
David Nicol proposed that, since the Received: headers are always
inserted in reverse chronological order, those headers could be
interleaved with the tags T in such a way that a relevant tag always
occurs above the latest Received: header. A spoofed T would end up
*below* the latest Received: header, and could be recognized at a glance.

I think this is a good idea, but is a bit fragile. The ordering of
header tags other than Received: is not necessarily honoured by a
transport agent. A more robust variation follows:

When a filter adds a tag T, it includes the specific date written in
the latest Received: line, as a form of authentication
information. This way, the tag T can be placed anywhere in the header.

If a spammer wanted to create a spoofed tag T, he would have to
predict the exact time which will be inserted in the Received: header by a
later MTA. (To make this absolutely impossible to predict, it may be
necessary to require MTAs to include the millisecond in the Received:
line, which the spammer would definitely not be able to predict.)

The advantage of this kind of authentication compared with say secret
passwords is this: the time inserted in Received: is a "public"
password, which doesn't need to be managed within an authentication
framework at all. Anyone can verify a message, at any time, even years
after the transport occurred, on a completely different system. 

Spammers are always on the wrong side, timewise, of the Received:
line, so they can never predict the date sufficiently accurately. 
Even better, there is no secret which can be compromised. Even if the
spammer hacks your system and views every single delivered message, 
he can't use any information to improve his chances of spoofing a tag
T correctly in the future. 

Ok, this is the basic idea. Now let's criticise/modify it.

-- 
Laird Breyer.