[plug] HTML mail (partial flame and suggestions)

[Tim White]

James Devenish wrote:

>Hi,
>
>In message <415BEBE5.4000307 at tigris.org>
>on Thu, Sep 30, 2004 at 07:20:05PM +0800, Tim White wrote:
>  
>
>>Secondaly could new subscribers be sent an email stating the acceptance 
>>or dislike of HTMl mail at the start with tips of how to turn it off for 
>>the common email clients (Mac, Win, and Linux)
>>    
>>
>
>I agree with this. I suggested it last month, but we have had a problem
>gathering all the things we would want to say in an introductory e-mail.
>I was thinking we could take a few salient points from the web page and
>a few from discussions on the list, and I intended to do that last
>weekend, or was it the weekend before? You know how the story goes...
>
>  
>
>>I have seen people recently being asked not to send HTML mail. This 
>>email is to ask a few questions and give a few suggestions.
>>    
>>
>
>If you had asked "what is wrong with using HTML e-mail on this list",
>answers would include:
>
> - Wasted bandwidth. I find that HTML e-mails are typically two to eight
>   times larger than their plain-text counterparts, with no value for a
>   typical message (note that some people also add pictures and
>   backgrounds to every HTML e-mail!). These extra bytes need to be
>   distributed to all the members of the list, which means much larger
>   bandwidth requirements for the *server* (hosted by a PLUG sponsor or
>   PLUG member). This extra bandwidth requirement hits the server both
>   when it sends the e-mail and when it serves up the web archives. It
>   also wastes disk space (the archives are already hundreds of
>   megabytes in size). An alternative is to filter all mail on the
>   server to convert HTML to plain text,
>
Would doing this solve lots of problems though? Especially if an HTML 
exploit is sent from a subscribers address, there are going to be some 
people on the list using Outlook because they don't know any better. I 
know this should be addressed on the client end but after reading the 
stuff below as well I am thinking that filtering all emails through 
'lynx -dump' or 'html2txt' or something similar may be benifitial on 
more than one way.

> etc. However, this is a bit
>   like our 'Message-ID' problem: people should not be sending bad
>   Message-IDs or HTML mail in the first place, as both are bad form /
>   bad etiquette. That is why the vocal preference is to have people
>   avoid these practices in the first place. Large S/MIME attachments
>   are also terrible in regard to size, but I cannot remember what
>   feelings were expressed on the list. I remember that the issues was
>   raised, at least.
> - Security. Plain text is largely "trustworthy", whereas HTML messages
>   can contain obfuscated links, web bugs, corrupt images, JavaScript,
>   and so forth. When HTML mail goes into the web archives, it cannot be
>   treated as trustworthy and needs to be processed to account for this.
>   Again, this should not really be necessary because the mail shouldn't
>   have been sent in such a format in the first place. Note that the
>   security issue hits the list moderators because we have to review
>   each 'held message' to see whether it is legitimate or not. In
>   reality, most of the messages are spam and viruses. Fortunately,
>   these are displayed by the web interface in 'raw source format' so
>   that they cannot trick our browsers into doing anything nasty.
>   Likewise, if you send HTML e-mail into the moderation queue, we'll
>   end up seeing your raw HTML in the web interface. This makes it
>   difficult for us to assess the merits of the contents of the message.
>   In practice, almost every message that is over 5kb in size in the
>   moderation queue is discarded. It is actually the quickest way to
>   differentiate spam and viruses from real mail, although in reality I
>   use a more careful set of tests.
>
Tim