On Wed, 2004-12-01 at 20:26, domainkeys-feedbackbase01(_at_)yahoo(_dot_)com
wrote:
--- Douglas Otis <dotis(_at_)mail-abuse(_dot_)org> wrote:
Something like- (see: rfc2822 & rfc2045/6/7)
H0 := "RECEIVED"
H1 := "MESSAGE-ID"
Even something as simple as an Adler-32 and length of the various
headers and fields could look something like...
MSTATE: H0:abd1:201f, H1:8734:0023, H5:AF04:0045, H2:09AF:0024,
H11:0345:0041, X-ACCEPT-LANGUAGE:05AF:0036, H10:8765:001F,
H6:9903:010B, H4:9987:0123, H22:31AC:0098, H20:AFED:01AC,
P1:AFCD:ACDF
Interestingly, we have discussed a similar concept within DK - as you say, it
offers a diagnostic benefit as well as identifying suspect headers - which can
still be rendered on advisement by a complying UA. We never got to the stage
of
formally documenting it, though we've used it on occasions internally.
Douglas. This "trace" information is amenable to any/all signature systems in
MASS, so what are you thoughts on codifying this in an I-D as a separate
header? If you did, it'd make it easy to write independent tools to test an
email against MSTATE: and I for one would be tempted to drop our DK-Trace:
header in preference to something common and well defined.
There are a few details regarding consistent normalizations
(canonicalization). As the goal is to be able to restore a failed
signature, these details are important. Perhaps I should include a
single nibble modulo to address header munging (change in capitalization
as example) where just bit 5 is summed and use 16 bit modulo values for
the hash and length for the headers and a 32 bit lengths for data
sections. I am not sure how important this header label concern is.
For headers, the nibble check is terminated by the ':'. The subsequent
hash includes the ':' and removes any local line terminator and appends
CRLF to the resulting string.
This would then look more like H0:7:AC1F:00F3, ...
-Doug