Alessandro Vesely wrote:
On 19/May/11 05:17, John Levine wrote:
And anyway, if your goal is for your message to survive, you should
armor it better, not come up with more arcane ways to declare that
it may be bleeding heavily but it's not dead yet.
Interesting, but not less intricate. The semantics of authenticating
only the armored part of a message is not obvious. Resorting to
base64 encoding is subject to varying interpretations, including
spammers attempts to avoid naive content filtering.
+1.
What has made all this very difficult is trying to make a technology
fundamentally based on authenticating integrity (DKIM) work with a
natural breaking "Message Massager" (Mailing List) and as a result we
have lowered its overall efficacy to an near absolute indeterminate
state of conditions. Even if the conversion is not required, you just
don't know if BASE64 MIME is done by the signer and/or mailing list.
Case in point. Right now, I am looking at a gmail.com which I am
pretty sure was not in Base64 MIME. However, it was submitted to IETF
DISCUSS group and its showing up as base64 MIME. I don't know if the
list did it one of the hops before the DKIM-Signature.
But the body hash failed. So I took the message, made a copy and
unbased64 the body, pulled the list footer and poof! - the body hash
was ok again.
It would of been nice to have some DKIM-Signature flag that might
indicate the Content-Transfer-Encoding, i.e.:
et="base64" <--- copy of the top level Content-Transfer-Encoding
then at least the verify will know the encoding type of original body.
If et= value does not match the current Content-Transfer-Encoding,
then it has some smarts do a unbase64 before hash verification.
Of course, it still would of failed due to the list footer so, but if
l= was used, there is some avenue for success.
The main realization is that Sender/Signers need to be more aware of
the target/path if they desire a higher rate of return.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html