HTML mail (was: PHP contact manager)

[Benjamin Scott]

On Sep 27 at 9:29am, Bill McGonigle wrote:
> Ben, you need a MUA that can handle multi-part MIME messages.  Set it to
> show you the text/plain alternative.

   I do, and I have.  :)  Pine 4.63, FYI.  Not only does it recognize MIME, it 
understands HTML mail, and does a passably decent job of rendering HTML mail 
for me, if I want.  However, I have set the "prefer-plain-text" option, since 
I do.  I tried viewing both versions in Pine.  Both were mangled.  I also 
tried piping the HTML version to Lynx.  It was still mangled.  I also tried 
viewing the contents of the message *raw*, using nothing more advanced then 
"less", and it was *still* mangled.

   That mangling was, and remains, my only complaint to Greg about HTML mail in 
this thread.  :-)

> But I see Greg's messages just fine.

   Perhaps you should look harder?  ;-)

On Sep 27 at 10:47am, Bill McGonigle wrote:
> It had a text/plain part and an HTML part.  Both parts had <url>'s inserted
> after each IP address in the message content.  I didn't see any HTML in the
> text/plain part.

   Same here.

> I just did a little test via GMail - here's what I got, in the text/plain
> part coming in from GMail:
>
>  192.168.0.1 <http://192.168.0.1>
>  192.168.0.2 <http://192.168.0.2>

   I ran similar tests.  I entered a bunch of URLs and bare IP addresses, 
typing them by hand each time.  I tried these tests in "plain text" and "rich 
text" (HTML) modes.  I even tried playing around with the "link" icon in the 
button-bar.  Here's what I found:

   --> URIs (as in http://www.example.com or http://192.0.2.1) are left alone 
if just typed in.  It doesn't even auto-linkify them in "rich text" mode, 
which I expected it to do.

   --> Creating a link using the "rich text" toolbar button embeds an HTML 
anchor tag in the text/html part, and uses the "link text with target 
following in angle-brackets" convention in the text/plain part.  That's 
reasonable, since the link text and the target can be two different things. 
(Phishers depend on this, in fact.)

   --> Typing in a bare IP address (like 192.0.2.1) without any URI around it, 
in "rich text" mode, will auto-linkify the IP address.  That is, it embeds an 
HTML anchor tag in the text/html part, and uses the angle-brackets in the 
text/plain part.  Switching to plain text mode, as you observed, fixes this.

   --> Using "rich text" mode causes Gmail to *eat white space* in the 
plain/text part.  Specifically, preceding whitespace is deleted, and interior 
whitespace is condensed to a single space character.  Gmail embeds &nbsp; 
non-breaking space tags in the HTML part.  *This* was actually causing my 
brain more grief then the linkification, since so many commands use whitespace 
for alignment in their output.

   Yah, I'd say there are some bugs!  :-)

>> However, I can assure you that it is not Ben's MUA that is causing the
>> problem in this situation,
>
> Ben said he was seeing HTML.

   Actually, I didn't.  I complained that HTML mail and HTMLization was 
mangling Greg's messages.  Which is sort-of true.  More accurately, Gmail's 
implementation of HTML mail is doing that.  This is one of the issues with 
HTML mail -- implementation is very inconsistent.

   As it happens, I *was* seeing HTML, both rendered, and unrendered ("raw 
HTML"), because I investigated the problem rather carefully.  ;-)

>> nor is mailman doing the wrong thing.
>
> What's the point of displaying the raw MIME body in the archive's _.html_
> page?

   I do agree that the behavior of the archives here is rather poor.  It's
almost as if the archive-creator-program is not aware of MIME, which is kinda
stupid for this day and age.

-- 
Ben <dragonhawk at iname.com>