Problem attaching files of type Text/HTML
Alexander Blewitt
/etc/mime.types file defines:
text/html html htm
and when I attach the message, it correctly reports the html file as
being of type 'TEXT/html'. (Don't know why it capitalises it).
However, if I then send the message to myself, the message I get back
claims to have an attachment type of 'TEXT/plain' instead, and when I
look at it it indeed comes across as plain text, HTML tags and all.
If I use another mailer, such as metasend, then it correctly gets
interpreted as HTML and I get pretty tags everywhere.
Does anyone know why a multipart mail message should loose its type as
it gets sent?
Alex.
Eduardo Chappa L.
I reported the same problem a few weeks ago, I received a message from
the pine team asking me for my .pine-debug files, and they answered me that
this one was a difficult one, they hadn't catch it yet. Up to the moment no
one has answered me why this occurs, if someone lets you know, please let
me know. I myself tried several ways to change the headers, and could not
do it.
Have a nice day,
Villy Kruse
Eduardo Chappa L. <cha...@math.washington.edu> wrote:
>Hello Alexander,
>
> I reported the same problem a few weeks ago, I received a message from
>the pine team asking me for my .pine-debug files, and they answered me that
>this one was a difficult one, they hadn't catch it yet. Up to the moment no
>one has answered me why this occurs, if someone lets you know, please let
>me know. I myself tried several ways to change the headers, and could not
>do it.
It should not be so difficult to reproduce. If you attach a html text
it is marked as text/plain and base64 encoding, also on version 4.10.
You can, however postpone the message and edit the postpone mailbox to
change the text/plain into text/html, and that sometimes even works.
That is not a solution, however.
Anyone out there who can't reproduce this?
Villy
isoma
>In article <Pine.OSF.4.10.990720...@goedel3.math.washington.edu>,
>
>It should not be so difficult to reproduce. If you attach a html text
>it is marked as text/plain and base64 encoding, also on version 4.10.
>
>You can, however postpone the message and edit the postpone mailbox to
>change the text/plain into text/html, and that sometimes even works.
>That is not a solution, however.
quoted-printable for those who haven't got MIME mailers?
--
mailto:is...@altavista.net - +44441089921 - Tim Bannister
http://www.jellybaby.net/~isoma/ - Spam? What spam? (pats procmail)
Terry Gray
Yes. Works fine for me.
I believe Eduardo is running on an OSF system... any similarity there?
-teg
On 21 Jul 1999, Villy Kruse wrote:
> In article <Pine.OSF.4.10.990720...@goedel3.math.washington.edu>,
> Eduardo Chappa L. <cha...@math.washington.edu> wrote:
> >Hello Alexander,
> >
> > I reported the same problem a few weeks ago, I received a message from
> >the pine team asking me for my .pine-debug files, and they answered me that
> >this one was a difficult one, they hadn't catch it yet. Up to the moment no
> >one has answered me why this occurs, if someone lets you know, please let
> >me know. I myself tried several ways to change the headers, and could not
> >do it.
>
> It should not be so difficult to reproduce. If you attach a html text
> it is marked as text/plain and base64 encoding, also on version 4.10.
>
> You can, however postpone the message and edit the postpone mailbox to
> change the text/plain into text/html, and that sometimes even works.
> That is not a solution, however.
>
Villy Kruse
Jeremy Blackman <lo...@maison-otaku.net> wrote:
>Hey, wait, me and one other person not only tracked this down but SUBMITTED
>A FIX several weeks ago. <grumble>
The pine people promise not to acknowlege any bug fix you might send.
Maybe they got it maybe they didn't. But that doesn't exactly encurage
anyone to submit more bugfixes. Give it time, and maybe it is fixed in
4.11.
>It's not, technically speaking, a bug in PINE. It is a bug in egcs/gcc,
>where in one particular case, an optimization causes a return result from
>one of the MIME handler routines to get utterly clobbered. (This is
>probably also why it does BASE64 encoding when quoted-printable would be
>more appropriate, but we didn't bother to try debugging that one.
>Step-debugging PINE for one bug is pain enough, thank you.)
The base64 encoding of all attachments has been a feature of pine at
least since 3.91 and seems to be independent of which compiler you use.
SCO unix, Motorola Unix, AIX, etc.
Villy
Jeremy Blackman
>the pine team asking me for my .pine-debug files, and they answered me that
>this one was a difficult one, they hadn't catch it yet. Up to the moment no
>one has answered me why this occurs, if someone lets you know, please let
>me know. I myself tried several ways to change the headers, and could not
>do it.
Hey, wait, me and one other person not only tracked this down but SUBMITTED
A FIX several weeks ago. <grumble>
It's not, technically speaking, a bug in PINE. It is a bug in egcs/gcc,
where in one particular case, an optimization causes a return result from
one of the MIME handler routines to get utterly clobbered. (This is
probably also why it does BASE64 encoding when quoted-printable would be
more appropriate, but we didn't bother to try debugging that one.
Step-debugging PINE for one bug is pain enough, thank you.)
I know for a fact that this bug affects x86 versions of egcs/gcc after 2.7.2
(because I tried it on a variety of machines), and I've been told by someone
that the Alpha architecture also has this problem. (The bug was submitted
to the egcs/gcc team, as well.) The bug causes the return to contain a '0',
no matter what the actual return result was, when the program returns to the
calling function - this causes PINE to assume certain (incorrect) defaults.
With a simple alteration to that particular routine in PINE to force
egcs/gcc to be unable to optimize that one step (e.g. add 'sleep(0);' before
the return), PINE correctly attaches things again. This particular bug
affects several MIME types, text/html is merely the most noticable.
The patch in question can be found at:
ftp://ftp.listar.org/pub/listar/other/pine4.10-mimetype.patch
(The bug was discovered while working on the MIME handling for the Listar
mailing list package, hence the location of the patch. There's also a patch
to add minimal RFC2369 support to PINE in that same directory, as
pine4.10-listserv.patch)
Hope that helps!
Eduardo Chappa L.
The problem about attachments of HTML files has been a topic of
discussion both in the pine-info list as in comp.mail.pine. The following
message appeared in comp.mail.pine. I tried the patch suggested there and
it worked! In my case uname -a says OSF1 goedel3 V4.0 878 alpha
Thanks for the patch, it certainly did solve this problem for me.
Eduardo
http://www.math.washington.edu/~chappa/personal.html
*** Jeremy Blackman (lo...@maison-otaku.net) wrote on Jul 25, 1999:
:)> I reported the same problem a few weeks ago, I received a message
:)> from the pine team asking me for my .pine-debug files, and they
:)> answered me that this one was a difficult one, they hadn't catch it
:)> yet. Up to the moment no one has answered me why this occurs, if
:)> someone lets you know, please let me know. I myself tried several
:)> ways to change the headers, and could not do it.
:)
:)
:) Hey, wait, me and one other person not only tracked this down but
:) SUBMITTED A FIX several weeks ago. <grumble>
:)
:) It's not, technically speaking, a bug in PINE. It is a bug in
:) egcs/gcc, where in one particular case, an optimization causes a
:) return result from one of the MIME handler routines to get utterly
:) clobbered. (This is probably also why it does BASE64 encoding when
:) quoted-printable would be more appropriate, but we didn't bother to
:) try debugging that one. Step-debugging PINE for one bug is pain
:) enough, thank you.)
:)
:) I know for a fact that this bug affects x86 versions of egcs/gcc
:) after 2.7.2 (because I tried it on a variety of machines), and I've
:) been told by someone that the Alpha architecture also has this
:) problem. (The bug was submitted to the egcs/gcc team, as well.)
:) The bug causes the return to contain a '0', no matter what the
:) actual return result was, when the program returns to the calling
:) function - this causes PINE to assume certain (incorrect) defaults.
:)
:) With a simple alteration to that particular routine in PINE to force
:) egcs/gcc to be unable to optimize that one step (e.g. add
:) 'sleep(0);' before the return), PINE correctly attaches things
:) again. This particular bug affects several MIME types, text/html is
:) merely the most noticable.
:)
:) The patch in question can be found at:
:) ftp://ftp.listar.org/pub/listar/other/pine4.10-mimetype.patch
:)
:) (The bug was discovered while working on the MIME handling for the
:) Listar mailing list package, hence the location of the patch.
:) There's also a patch to add minimal RFC2369 support to PINE in that
:) same directory, as pine4.10-listserv.patch)
:)
:) Hope that helps!
:)
:)
:)
:)