What's the point of inserting such a Processed: header anywhere before
final delivery?
In the event of a message that appears to have traversed A --> M1 -->
M2 --> B, there's no way for B to validate the Processed: headers that
seem to have been added by M1 -- because it may be that M1 is really
the bad guy, and he's just making it look like he's transmitting a
message from A -- so of what use are they?
Why not just specify that M2 should discard all Processed: headers
that it receives, just as it would do for Return-Path:, and then you
can always trust whatever such headers are present, and there's no
reason to tie them to a token in the Received: line?
Or write the spec in terms of trust relationships, such that if M2
trusts M1 then it can accept all Processed: headers, but otherwise it
must discard them. Transitively this means that if the path was A -->
M0 --> M1 --> M2 --> B then M1 must have thown away all Processed:
headers if M0 is untrusted, so it's safe for M2 to accept whatever M1
presents.
(Any untrusted MTA anywhere in the chain could mung the existing
Processed: headers, so there's no point in preserving them across any
hop that isn't known to implement the spec, is there?)