Tried to make this a bit clearer in imp/docs/INSTALL.

No.  I am saying that this is working correctly, where the 'signature' to

the message correctly is not listed as an attachment but is displayed

properly embedded in the HTML e-mail.  You mentioned that the image

shouldn't display on its own, and that's correct- it displays by the img

tag embedded in the HTML message.
Dating back to the design choices of HTML e-mail, but not the issue

for here.
I'm a strong believer of this, however somehow I missed this

option.  It's a fairly important option, that I'm sure is very

commonly changed.  Might it be wise to make this more obvious

such as a configuration option or place some note in the installation

documentation on it?
Didn't know there was a generally accepted system for that.

I guess what I was thinking it as what the user would see

as intutitve, but that should be implied based on what most

mailers will do.  Thanks for the explaination.







So in the end, I think we squashed the bug relating to #2 and a couple 
earlier in the thread.  I'd recommend adding a more obvious 
documentation note at the html inline option, but I'll leave that up 
to you folks.



Thanks again!

Are you saying that if this is in there that the image isn't displayed 
when viewed in a pop-up window?  I can't reproduce this.

But, as mime_drivers.php clearly states, allowing HTML messages to be 
viewed automatically (or at all) can open huge security holes.  We try 
to strip the HTML of "bad tags" as best as possible, but readily admit 
it is not 100% perfect.  So we have decided to go with the OpenBSD 
method of "secure by default" and leave it up to the individual admin 
to activate this feature and accept the potential issues associated 
with activating it.



Additionally your description of how the MIME system decides which 
parts to show appears to be a bit off.  You suggest that a text part 
should "ideally" take priority and then HTML if a text part doesn't 
exist.  THis is incorrect.  Text parts don't take priority over *any* 
parts.  There is no RFC that says this, and this is certainly not what 
we do.  Instead, we ask the admin (through mime_drivers.php) which 
MIME types they would like to display inline.  Then we use RFC rules 
to determine what parts should be displayed.



For example, with multipart/alternative, the RFC clearly states that 
the most feature rich element of that multipart that can be displayed 
by the software should be presented to the user - and the 
"feature-richness" is determined by the order the part appears in the 
multipart.  We have no say in which part is shown - it is completely 
determined by what types the user has defined to display inline in 
mime_drivers.php and the structure of the message.  If a user wants to 
disable text/plain parts, they are more than welcome to do this - no 
matter how badly it may stunt their effective use of the software.

Correct.  The image is referenced in the HTML. I

stripped it out with all of the extra parts.  They

have this:

<IMG alt="" hspace=0 src="cid:000001"

  align=baseline border=0>

in order to display the image
I believe that this should be the default then, as

a new installation of horde (as I did for 3.2) has

this set to false by default.  Ideally, text should

take priority, but no text part should then return

the html message if it exists.  At present a clean

distribution of imp has html inline set to false.

I'm against HTML mail as with many, but it's a little

too commonplace these days to ignore as more people

send just html.
I see this has been marked as fixed.  Thank you.
Okay, but do see my note as making this the default

for future installations.

The issue identified in #2 below has been fixed.

Comments on your sample e-mails:

1. "goldmine e-mail"

Renders properly here.  There *shouldn't* be a link to the image since 
this is a multipart/related part.  Unless the image data is referenced 
in the text/html part, then it isn't visible.  Additionally, that is a 
seriously broken message (or at the best a very sloppily constructed 
one).



If "goldmine"'s intention is to display a slogan at the bottom of 
every message, they need to either put an <img> tag into the text/html 
part or they need to send their messages as multipart/mixed.  We can't 
fix the way other MUA's send messages though.  You need to take this 
up with them.



If you are not seeing this message in-line, then that is the way *you* 
configured IMP.  If you go to imp/config/mime_drivers.php, I can 
guarantee you that you have this line:

$mime_drivers['imp']['html']['inline'] = false;

If you want inline display of HTML messages, then this has to be true.



2. "2nd goldmine message"

There is an error here with not displaying the HTML part.  This will 
need to be fixed.  Nothing else is wrong with the rendering of this 
part.



3. See #1.  IMP is rendering correctly.



4. See #1.  IMP is rendering correctly.

The wost case of these is the second one, where there is no way to get 
the body of the message without clicking reply.



The others are just inconvinient, as it should really be displaying 
the HTML message if no plain text part exists in an inline form.

This issue remains in -RC2



I have included four samples still experiencing this issue.  Two are 
from goldmine.  One is a newsletter from MCI and another is a 
newsletter from Microsoft (their weekly mailing).



The attached file also describes what I show in all of those cases.

RC2 of Horde and IMP have been released, please try now.

So if it works in the current soon to be RC2 then this bug is 
essentially closed.  Was just making sure in repeating it, because 
there were some ambiguities in what I wrote.



Thanks for your help.  I'll look forward to the next release.

We don't care what happens in the current stable releases since we 
aren't fixing any bugs there anymore.
Did you see my previous post?  I mentioned I tested on -rc2 and it 
worked fine.

-rc1 is old any many things have been fixed since then.

To clarify:



current stable releases:

  - unable to even see the part except for viewing source

  - replying to the message shows the proper text quoted in the reply e-mail

  - part completely missing even in attachment of all parts



current unstable release (-rc1)

  - part does not display automatically in the message body (as it 
probably should)

  - however it does show that the part exists and allows you to click 
on it, displaying the HTML message.



I think the only thing left to do (Not sure if the report says this is 
fixed in the head release) is to have it display the part 
automatically since in the text/html part of the multipart/related set 
doesn't seem to in either of the versions I have tested.

Works fine for me using the latest versions of FRAMEWORK_3 (soon to be 
Horde 3.1.0-RC2 and IMP 4.1.0-RC2).

Using imp 4.1-rc1 and 3.1-rc1 horde, It now displays an 'unnamed' 
'multipart/related' part and displays the image (that's the case of 
all of these- embedded images for use in the HTML) when viewing the 
HTML.



It still doesn't display inline (you have to click on it for it to 
open).  If there is one part and it's text or html, shouldn't it just 
be displayed?

Will get on this and give it a test.



Current versions:

  Horde: 3.0.9

  IMP (mail): 4.0.4

  Notes (mnemo) H3 (2.0.2)

  Address Book (turba) H3 (2.0.4)



Actually an interesting thing to note is that if I click reply, the 
proper text appears in the reply window (I guess sanitized from HTML 
to plain text as well).  So it can obviously decode and get the part 
out, but it just isn't displaying it or giving the option to display it.

Can you test against the 4.1 RC and see if this still happens? The 
Horde version might be even more important; what version do you have, 
and what if you try the Horde 3.1 RC?

Same thing with a message created by PHPMailer that I received.  There 
were a few more images but I cut those out entirely...



X-Mailer: PHPMailer [version 1.71]

MIME-Version: 1.0

Content-Type: multipart/related;

        type="text/html";

        boundary="b1_a81f5452df6cf8722586d5c1f544a751"



--b1_a81f5452df6cf8722586d5c1f544a751

Content-Type: text/html; charset = "iso-8859-1"

Content-Transfer-Encoding: 8bit



<html>



**** SNIP ****



</html>



--b1_a81f5452df6cf8722586d5c1f544a751

Content-Type: image/gif; name="logo5-small.gif"

Content-Transfer-Encoding: base64

Content-ID: <my-attach1>

Content-Disposition: inline; filename="logo5-small.gif"



**** SNIP ****





--b1_a81f5452df6cf8722586d5c1f544a751

Content-Type: image/gif; name="newsgrid-htrt-468x60-v4.1_2.gif"

Content-Transfer-Encoding: base64

Content-ID: <my-attach2>

Content-Disposition: inline; filename="newsgrid-htrt-468x60-v4.1_2.gif"



**** SNIP ****



--b1_a81f5452df6cf8722586d5c1f544a751--

A MIME message from Goldmine (in fact, all Mime messages I seem to get 
from goldmine) look like the one below (most of the content stripped 
for size purposes as well as unimportant headers).  To you and I, this 
of course should show the text/html part of the message off the bat.   
Instead not only does it state that "There are no parts that can be 
displayed inline.", but it also doesn't display any parts at all.  It 
shows no attachments, yet downloading all attachments in a zip file 
gives me only the gif image (the second part), and you completely 
loose the first part.  They only way it seems to view it is to view 
the message source.



Now this may very-well be Goldmine's fault, but it seems like the 
right thing to do is try and make sense of what the message is doing 
in order to display something, rather than show a blank/empty mail 
with no hopes of obtaining the message unless you look at the message 
source.



Thoughts?





---------------------------------------

Mime-Version: 1.0

X-Mailer: GoldMine [7.00.51018]

Content-Type: multipart/related; boundary="nqp=nb64=()p1KaLmIg2"



--nqp=nb64=()p1KaLmIg2

Content-Type: text/html



<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0

  Transitional//EN">

<HTML><HEAD>

<STYLE type=text/css> P, UL, OL, DL, DIR,

  MENU, PRE { margin: 0 auto;}</STYLE>



<META content="MSHTML 6.00.2900.2802" name=GENERATOR></HEAD>

<BODY leftMargin=1 topMargin=1 rightMargin=1><FONT

  face=Tahoma size=2>

<DIV>Hi Michael,</DIV>

<DIV></DIV></BODY></HTML>

--nqp=nb64=()p1KaLmIg2

Content-Type: image/gif; name="Slogan.gif"

Content-ID: <000001>

Content-Disposition: inline; filename="Slogan.gif"

Content-Transfer-Encoding: base64



R0lGODlh4QCLAOYAAMDAwEBAQP+/AIxWm7OOvdnH3ri4uJSUlNzc3BAQEPDw8NDQ0CAgIODg

**** SNIPPED ****

GyQOMhIihiSWaOKJKKao4ooqhpbQA3+xKOOMNNZo4402LtAfA/HgKEggADs=



--nqp=nb64=()p1KaLmIg2--