Michael Thomas wrote:
On Wed, 7 Feb 2007, Mark Sapiro wrote:
Mike talks about the l= parameter allowing adding trailing content, but I don't see Y! and Gmail using it, and even if they did, how would we (could we) add a footer without breaking either the signature or the MIME structure of the message.
l= is the number of canonical bytes added to the body hash. If l=5, for example, anything past the 5th canonical byte will not affect the verification of the signature. That's the reason we get such high verify rates through mailing lists.
My point is that for what I consider good reasons, Mailman will add the msg_footer to such a message by wrapping additional MIME structure around the original multipart/alternative message.
I.e., the original
multipart/alternative text/plain text/html
message will be recast as
multipart/mixed multipart/alternative text/plain text/html text/plain
with the final text/plain part containing the footer. Given that the original content-type header is included in the signature, the signature is now broken.
If we were to take a different approach with a signature containing l=, either the l= includes all the text/plain and at least part of the text/html, in which we can't add the footer to the text/plain alternative without breaking the signature, or the l= includes none of the text/html part in which case the signature is not very good at verifying the validity of the text/html part. This further assumes we even know how to add a footer to a text/html part.
See <http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq04.039.htp> for some discussion of why we do it the way we do.
-- Mark Sapiro <msapiro@value.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Mark Sapiro wrote:
Michael Thomas wrote: My point is that for what I consider good reasons, Mailman will add the msg_footer to such a message by wrapping additional MIME structure around the original multipart/alternative message.
I.e., the original
multipart/alternative text/plain text/html
message will be recast as
multipart/mixed multipart/alternative text/plain text/html text/plain
Ah yes, multipart/alternative vs. lists is definitely unhappy for DKIM, though simpler mime layouts make it through on average -- at least given our sample. I agree that if you have to add a footer at all, that the way your doing it in this case seems perfectly reasonable.
with the final text/plain part containing the footer. Given that the original content-type header is included in the signature, the signature is now broken.
If we were to take a different approach with a signature containing l=, either the l= includes all the text/plain and at least part of the text/html, in which we can't add the footer to the text/plain alternative without breaking the signature, or the l= includes none of the text/html part in which case the signature is not very good at verifying the validity of the text/html part. This further assumes we even know how to add a footer to a text/html part.
Are you still speaking of multipart/alernative? Right now what we do for, say, text/html is not sign the trailing </body></html> and final --. This allows lists to insert their trailers as they normally do in the mime/html body. Similar for text/plain too. For us at least (and it may be that we're just have a lot of html hating geeks), this seems to do the trick pretty well. I see some breakage from multipart/ alternative, but not _that_ much.
MikeMichael Thomas wrote:
Mark Sapiro wrote:
If we were to take a different approach with a signature containing l=, either the l= includes all the text/plain and at least part of the text/html, in which we can't add the footer to the text/plain alternative without breaking the signature, or the l= includes none of the text/html part in which case the signature is not very good at verifying the validity of the text/html part. This further assumes we even know how to add a footer to a text/html part.
Are you still speaking of multipart/alernative?
Yes, I am.
Right now what we do for, say, text/html is not sign the trailing </body></html> and final --. This allows lists to insert their trailers as they normally do in the mime/html body.
This assumes that something appended to an html body will render in a nice way. Maybe it will in most cases, but there's no guarantee.
Similar for text/plain too. For us at least (and it may be that we're just have a lot of html hating geeks), this seems to do the trick pretty well. I see some breakage from multipart/ alternative, but not _that_ much.
I'm not sure how typical your Mailman environment is. For regular, non-geek lists, I think that most posts from Y! will be multipart/alternative, and I think that will be a problem if the MLM touches the message body in almost any way.
-- Mark Sapiro <msapiro@value.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Mark Sapiro wrote:
Michael Thomas wrote:
Similar for text/plain too. For us at least (and it may be that we're just have a lot of html hating geeks), this seems to do the trick pretty well. I see some breakage from multipart/ alternative, but not _that_ much.
I'm not sure how typical your Mailman environment is. For regular, non-geek lists, I think that most posts from Y! will be multipart/alternative, and I think that will be a problem if the MLM touches the message body in almost any way.
You're possibly right. Is there any way to know though? Some stats around this would go a long way to helping inform this...
Mike
participants (2)
-
Mark Sapiro -
Michael Thomas