[MlMt] Any way to reload MmMessagesWebView/stylesheet.css at runtime?

Philip Paeps philip at trouble.is
Fri Jan 29 11:04:52 EST 2016

On 2016-01-29 16:08:33 (+0100), Benny Kjær Nielsen 
<mailinglist at freron.com> wrote:
> On 27 Jan 2016, at 23:56, Philip Paeps wrote:
>> How would I go about changing the style of partially signed messages? 
>>  I am guessing it's something like this but with different `type=` 
>> and `subtype=` parameters.
>> div.bodypart[type=message][subtype=rfc822] { }
> No, that would target embedded emails (“Forward as Attachment”).
> [...]
> It was a quick hack to make sure that MailMate clearly indicates if 
> someone has taken a signed email and extended its content with 
> unsigned body part(s). This is essentially what often happens on the 
> mailing list when the footer is added.

I really like this feature, quick hack or no!  It's nice to be able to 
distinguish in a message with some parts signed and some parts not, 
which parts and signed (and whether I can trust them).  The 
green/yellow/red borders around different parts of the message are 
great.  Except with my stylesheet.css tinkering I got very low-contrast 
bright yellow on dim yellow.

Note that this message is actually a good example: the Apple security 
mail you included was signed and MailMate shows exactly which parts are 
signed and which parts aren't.  Excellent.

> I've now changed it such that you can style it with a custom 
> stylesheet. Look for `div.security` in the default stylesheet. I 
> haven't changed how it looks (which is pretty ugly). You are welcome 
> to share it if you come up with something better.

Thanks!  I'll tinker with this some more (see if I can make the yellow 
on yellow go away) and share my diff against stylesheet.css in case 
anyone wants it.

> At least it appears it's not possible to put the unsigned content 
> before the signed content. It doesn't trigger a warning, but Apple 
> Mail then simply ignores that the message has signed parts at all.

Arguably, being able to prepend or append data without clear indication 
that this has been done is equally bad.  Imagine an email with a signed 
invoice which has been intercepted and mangled by an attacker to include 
"please pay XXX to our account YYYY" below the invoice.  Contrived 
example perhaps, but it's Friday afternoon, I couldn't think of anything 

> I just realized that it *is* possible to make the signed part appear 
> as an attachment. By providing a filename then it's even possible to 
> make it appear as if it's some kind of failed logo. [...]

Oops.  That is terrible.  That makes it look like the whole message has 
been signed.  If all you need to make a whole message look like it's 
signed by a trustworthy sender, is any trusted message from such a 
sender, you can cause a lot of trouble.

> I haven't checked any other email clients, but I doubt it's a common 
> issue. I'm guessing most email clients would just ignore that the 
> email is signed and/or encrypted.

The only other client I have significant experience with is Mutt, which 
like MailMate tells you the status of each part of multipart messages.  
Something like:

     [-- Attachment #1 --]
     [-- Type: multipart/signed, Encoding: 7bit, Size: 1.5K --]

     [-- PGP output follows (current time: Fri Jan 29 16:30:28 2016) --]
     This is the literal output from gpg --verify.  Mutt allows you to
     highlight based on regular expressions so it's easy to highlight
     whether the signature is good or bad and what's wrong with it if
     it's bad.
     [-- End of PGP output --]

     [-- The following data is signed --]

     The signed part is here.  If there are multiple signed parts, they
     are individually delimited with [-- --] markers like this.

     [-- End of signed data --]

     [-- Attachment #2 --]
     [-- Type: text/plain, Encoding: 7bit, Size: 0.1K --]

     This would be a mailing list footer for instance.

Mutt displays OpenPGP and S/MIME signed messages identically (only with 
the output from OpenSSL rather than GnuPG, obviously).  It's pretty 
clear to identify which parts are signed and which parts aren't.

> Also don't interpret it as me stating that MailMate is more secure 
> than Apple Mail.

As far as PGP and S/MIME go, I think you're doing a much better job than 
Mail.app.  It's very important to be able to tell which parts are signed 
and which parts aren't in a complex multipart message.  Being able to 
make a whole message appear to be signed by including a signed 
attachment is simply terrible.

> I have attached the example email if anyone wants to try it out in 
> Apple Mail or other email clients. That should also test how MailMate 
> handles it...

I've looked at this message in Mutt.  It's pretty clear which part is 
signed and which part isn't.  My Mutt doesn't have access to root 
certificates (I get very little S/MIME mail, and those people I get it 
from, are explicitly trusted) so it can't tell me anything about how 
trustworthy the signed part is, but it tells me which part it is.

     [-- Attachment #3: The world is going under tomorrow.eml --]
     [-- Type: message/rfc822, Encoding: 7bit, Size: 7.3K --]

     Date: Sun, 16 Jan 2013 16:31:36 -0800
     Message-id: <9C3B25F9-EB27-4356-A1C5-782EBE70AD3F at apple.com>

     [-- Attachment #1: logo.png --]
     [-- Type: multipart/signed, Encoding: 7bit, Size: 6.6K --]

     [-- OpenSSL output follows (current time: Fri Jan 29 16:35:20 2016) 
     [-- End of OpenSSL output --]

     [-- The following data is signed --]

     I’ve noticed that in some systems [...]

     [-- End of signed data --]

     [-- Attachment #2 --]
     [-- Type: text/plain, Encoding: 7bit, Size: 0.1K --]

     This text is unsigned. [...]

     [-- Attachment #3: attachment.txt --]
     [-- Type: text/plain, Encoding: 7bit, Size: 0.1K --]

     The same goes for attachments.

     [-- Attachment #4 --]
     [-- Type: text/plain, Encoding: base64, Size: 0.2K --]

     (mailing list footer here)

> ...and this shows that MailMate does not like the `attachment` 
> disposition of the `multipart/signed` body part. It is shown both 
> inline (as it should) and as an attachment (which is shouldn't). 
> Worse, clicking “Quick Look” shows the wrong attachment.

Oops. :-)

Once upon a time, there was a MIME test suite on the web at 
http://www.imc.org/mimetest/.  It's been taken offline because it was 
being abused by spammers.  Perhaps you can still find it on archive.org 
though.  If not: one of its authors uses MailMate and is subscribed to 
this mailing list (small world).  Perhaps he has a local copy. ;-)

> Hold down ⌥ when clicking “Check Now” in the Software Update 
> preferences pane to get the test release.

Excellent!  Many thanks!

>> A few more comments in stylesheet.css would be helpful. :)
> Apparently I'm too busy ranting on the mailing list :-)

I know how you feel. :)


Philip Paeps
Senior Reality Engineer
Ministry of Information
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freron.com/pipermail/mailmate/attachments/20160129/7593b92a/attachment.html>

More information about the mailmate mailing list