On Wed, 03 Jan 2007 21:38:41 -0000, william(at)elan.net <[EMAIL PROTECTED]>
wrote:
On Tue, 2 Jan 2007, John Levine wrote:
No. What you'd want to do is to rename modified header field into some
sort of trace data and copy the original data in its place. Displaying
modification would then be up to the MUA which could display small
icon allowing user to see what the modification was as an option.
An example of that sort of thing is the downrading process in EAI.
You start with some header
Foo-Header: <utf-8 stuff that wont pass through current MTAs>
and when you find yourself compelled to downgrade it because the next MTA
doesn't advertise the UTF8SMTP capability, you replace it with:
Foo-Header: <inadequate/partial reformulation of the original in ASCII>
Downgraded: Foo-Header: <RFC 2047 encoded representation of the original
utf-8>
So if the original Foo-Header was included in the signature, the signature
is now broken.
One possiblity for subsequently verifying the signature, assuming the
verifier can be made aware of what has happened (that is where the 'z='
tag might be needed) is for the verifier to reconstruct the original
Foo-Header from the Downgraded header, and test the signature on that.
I am not saying that this is the only way or even the best way of handling
DKIM in an EAI envireonment, because it is not yet clear whether the
mechanisms that have been proposed for downgrading are sufficiently
robust, but it is certainly one possibility that has been suggested. And
whether people will bother to write verifiers that do all that is another
issue again, but at least the possibility exists.
--
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131
Web: http://www.cs.man.ac.uk/~chl
Email:[EMAIL PROTECTED]: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
