Further testing of downgrade with a second EAI implementation was
successful on several cases where the first test had failed. Analysis
led to the conclusion that the failures on the first tests were due
primarily to an invalid continuation line in a header (contained a blank
line). The second implementation also had an error in a header line
(exceeded 80 length) but the email systems tested against were robust to
this error. There were no clear cases of failure that could be
attributed to introducing an unknown header into the email system.
Based on this (note it is still a small test sample), it seems
reasonable to consider keeping Downgraded headers. If we accept the
simplified design goal for Downgrade that abandons any attempt to
recover the original EAI information from downgraded headers to display
to the user, then the only value of such headers is to provide audit
trail information for email administrators or advanced users. However,
these headers are not humanly readable. Here is an example from from one
of the tests:
Downgraded-From: =?UTF-8?B?zpXPgc69zrnOtQ==?=
=?UTF-8?B?zpTOsc65zr3Ov8+J?=<=?UTF-8?B?zrXPgc69QM+AzrHOs866z4zPg868zrnOv
y3PhM6xz4fPhc60z4HOv868zrXOr86/?=
=?UTF-8?B?LmluZm8=?= <
edainow@...>>
There is a range of choices:
1) keep all downgraded headers as described in RFC5504, Section 3.
2) keep only Downgraded-From (and perhaps a few others)
3) drop all downgraded headers
My preference would be for 3) as the ultimate simplification. However, I
have never been an email administrator and may be underestimating the
value of the information these headers provide.
-Ernie Dainow
_______________________________________________
IMA mailing list
IMA@...
https://www.ietf.org/mailman/listinfo/ima
