Re: [Bulk] Re: Email encodings (was Re: [gentoo-user] Gentoo speed comparison to other distros )

[Michael Mol <mikemol@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3990 bytes --]

On 03/19/2013 05:09 PM, Kevin Chadwick wrote:
>> If you're going to call me out for ignoring things, missing things or
>> simply not  knowing things, please highlight what it is. "the quote"
>> isn't very enlightening in this context. You have a nasty habit of
>> referencing things without inlining them or referencing them directly,
>> and this has gotten in the way of clear communication *multiple* times
>> over the last week.
>>
>>> I only wrote two lines and you still missed it  
>>
>> I respond to what's written in the email I'm replying to, because that's
>> what I've just read, and that's the context of the email.
>>
>>> never mind the examples I had given in my original mail that do not
>>> only apply to remote content and that you wrongly interpreted.  
>>
>> Honestly, I never expected you to be up in arms over being exposed to
>> HTML syntax.
>>
>> I presumed you were concerned about libpng, libjpeg, swf and gif.
> 
> As I clearly said both, but actually less so html. You seem to be under
> the impression Androids mail clients let you avoid all that but they do
> not. Talk about hitting your head against a brick wall.

I can't tell any more whether you're complaining about people sending
HTML, whether you're complaining about receiving HTML emails without
being able to avoid parsing them, or whether you're complaining about
other people receiving HTML emails and their being placed at risk of
parsing bugs as a result.

If you're complaining about other people sending HTML emails: OK, fine.
Politely point out to them that it's common courtesy not to send HTML
emails. PLONK them if you need to. But make it clear this is what you're
complaining about. I don't see the relevance of most of your arguments
if your complaint is with other people sending HTML messages.

If you're complaining about receiving HTML emails without being able to
avoid parsing them: You're clearly technical enough to implement some
solution to avoid it. One solution would be to grab the source of an
existing mail client and patch it to not handle the HTML parts. Another
solution would be to have your mail pass through a server which strips
messages of those parts, or modifies them in some way to make them safe.
Yet another solution would be to find a mail client which does this for
you. I see no reason to continue raging about the state of the mail
clients you use, if this is your argument.

If you're complaining about other people receiving HTML emails and their
being placed at risk of parsing bugs, then provide a solution (I
detailed a few in the above paragraph) and allow them to adopt it if
they wish.

If what you're complaining about isn't enumerated above, please try to
state it simply and clearly.

> 
>> I
>> presumed you were concerned about privacy concerns. Those are what most
>> people who gripe about HTML email security are concerned with.
> 
> That would be to do with scripts and remote content.
> 
> Remote content Is as you have said almost always switchable and so was
> not a concern/thought of mine but yes, what people shout about. Scripts,
> well with Googles love of javascript (for obvious tracking reasons) I
> wouldn't be too surprised if that is enabled without recourse on
> android email.

I'm pretty sure I've never seen JS in email. Traditionally, tracking is
done with image bugs. There's little to no point in using scripting in
emails. And given Google is pushing as fast as they can away from RSS
and toward Google+, I'm rather expecting them to look for ways to get
away from email and XMPP, too.

Further, most GMail users use the web interface; there's No Way In Hell
Google would allow mail-delivered code to be executed from within that
security context. That would be the fastlane to account hijacking.

This argument boils down to: "I don't trust Google, so I'd like to
suggest they would use JS in emails, because that's scary, too."




[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 555 bytes --]