On Thursday 21 June 2001 23:06 asorensen@ucsd.edu wrote:
|   Package: kmail
|   Version: 1.2 (using KDE 2.1.1 )
|
|   When I try to send attachments using kmail they almost always get
| mangled.  PDF files in particular don't seem to be handled correctly.  If=
 I
| compose a message and attach "test.pdf" (a valid PDF document that I can
| read just fine using Acrobat) three times using (respectively)
| 8bit/base64/quoted-printable options the message looks like what I've
| inserted below.

Hi I experienced similar problem but with text files.
I  think *easy fix* / hack for you will be to change Chrset to iso8859-1 or=
=20
whatever 8-bit encoding (UTF8 is also ok).=20
Looking onto your header:
   Content-Type: application/pdf;
     charset=3D"us-ascii";
     name=3D"test.pdf"
I guess _charset=3D"us-ascii";_ is causing the problem.
Isn't it 7-bit encoding?
BTW: are your PDF files 7-bit encoded?
You can output PostScript files as7-bit ASCII may be that's was the reason=
=20
while you were able to send PS files.

My problem was in:
   Content-Type: text/plain;
     charset=3D"koi8-r";
     name=3D"mytext_in_cp1251.txt"

mytext_in_cp1251.txt was text file I created in Windows using Windows-cp12=
51=20
(Cyrillic) encoding.
THIS PROBLEM CAN'T BE REPRODUCED IF RECEIVER HAS KMAIL.
You need to send this message to user with MS Outlook
(I think both Outlook and Outlook 2000 are affected) or open it in your=20
Windows.
=20=20
What Outlook was doing/ *thinking*:
1) I received text in koi8-r
2) user has cp1251 system setting/encoding
3) he opens the file - ok let's recode it to right encoding.
After it Outlook was recoding mytext_in_cp1251.txt to _cp1251_ encoding.
But as it was already in cp1251 encoding everything became completely=20
messed.

I did study what Netscape Messanger was putting in attachement header.
Actually it was not putting "charset=3D"koi8-r" at all!
(the same is MS Outlook)
I guess such header:
- - -=20
   Content-Type: text/plain;
     name=3D"mytext_in_cp1251.txt"
- - -=20
is also pretty valid charset=3D is *not required*

So what I did:
* I saved my message fron KMail/outbox to disk
* deleted charset=3D"koi8-r"; from message attachement descr. (with text ed=
itor)
* saved it disk as mymsg.eml
* Opened it with Outlook

Voila!  No problem attachement was opened correctly.
I hope that this bug can be corrected for KDE 2.2 release (or may be even=
=20
for upcoming KDE 2.2beta1)
=20

|   (note that this is what it looks like _before_ it gets sent...so the
| problem must be in the encoding?)
|
|   If I send text files as attachments they work fine.  I've also been ab=
le
| to send postscript files with some success.
|
|   Whether this is a bug or something I'm doing wrong it has been driving
| me crazy for the past couple of months.  Please help!
|
|
|   From asorensen@ucsd.edu Thu Jun 21 16:02:29 2001
|   Content-Type: Multipart/Mixed;
|     charset=3D"us-ascii";
|     boundary=3D"------------Boundary-00=3D_5OYA16Q2OVHQO96UH12R"
|   From: Alan Sorensen <asorensen@ucsd.edu>
|   Organization: UCSD Economics
|   To: asorensen@ucsd.edu
|   Subject: testing pdf attachments
|   Date: Thu 21 Jun 2001 16:02:29 -0700
|   X-Mailer: KMail [version 1.2]
|   MIME-Version: 1.0
|   Message-Id: <0106211602290B.08843@sorensen.ucsd.edu>
|   Status: RO
|   X-Status: Q
|
|
|   --------------Boundary-00=3D_5OYA16Q2OVHQO96UH12R
|   Content-Type: text/plain;
|     charset=3D"us-ascii"
|   Content-Transfer-Encoding: quoted-printable
|
|   three attachments.  none work.  what's up?
|
|
|   --------------Boundary-00=3D_5OYA16Q2OVHQO96UH12R
|   Content-Type: application/pdf;
|     charset=3D"us-ascii";
|     name=3D"test.pdf"
|   Content-Transfer-Encoding: 8bit
|   Content-Disposition: attachment; filename=3D"test.pdf"
|
|   %PDF-1.2
|   %=C7=EC?=A2
|   4 0 obj
|   <</Length 5 0 R/Filter /FlateDecode>>
|   stream
|   x?3=D03T0
|   --------------Boundary-00=3D_5OYA16Q2OVHQO96UH12R
|   Content-Type: application/pdf;
|     charset=3D"us-ascii";
|     name=3D"test.pdf"
|   Content-Transfer-Encoding: base64
|   Content-Disposition: attachment; filename=3D"test.pdf"
--=20

Vadim Plessky
http://kde2.newmail.ru  (English)
33 Window Decorations and 6 Widget Styles for KDE
http://kde2.newmail.ru/kde_themes.html
Do you have Arial font installed? Just test it!
http://kde2.newmail.ru/font_test_arial.html

Vladim

Thanks for the suggestion.  This fix doesn't seem to work however.  I=20
tried changing the default charset in kmail and I tried manually=20
deleting the "charset=3D" line from the file -- doesn't help.  I admit I=20
know very little about these things but what strikes me as odd is that=20
the "attached file" is so much smaller than the actual file.=20=20

In fact after looking at the problem more closely it really seems=20
like the problem is in the encoding.  As a stark example I tried=20
sending the same large PDF file (a 40-page academic article) from=20
Eudora (Windows) and Kmail using base64 encoding.  (The Eudora=20
attachment works fine the kmail attachment doesn't.)  Looking at my=20
~/Mail/inbox file the attachment in the Eudora message is many hundred=20
lines of garbled text; the message from kmail is exactly two lines of=20
garbled text.  Those first two lines precisely match the first two=20
lines of the Eudora attachment so it's starting out OK....but why is=20
it cutting off the file?

Here's what it looks like:

--------------Boundary-00=3D_WU9CHY67PQZKWZJP4WLK
Content-Type: application/pdf;
  charset=3D"iso-8859-1";
  name=3D"benkard.pdf"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=3D"benkard.pdf"

JVBERi0xLjIKJeLjz9MNCjIgMCBvYmoKPDwKL0xlbmd0aCAyOTM1Ci9GaWx0ZXIgL0ZsYXRlRGVj
b2RlCj4+CnN0cmVhbQ0KSIl0V9ly48YVfddX8LGRGsLoBVvexnbsTCpOuTxK8uDkAQIhChEJsA=
=3D=3D

--------------Boundary-00=3D_WU9CHY67PQZKWZJP4WLK--

(The obvious differences between the attachment that works and the one=20
that doesn't are (a) the kmail attachment has the seemingly unnecessary=20
"charset=3D" line and (b) the kmail attachment is apparently truncated.=20=
=20
Fixing (a) may be easy but that can't possibly resolve (b).)

Still looking forward to any suggestions....

Alan



On Friday 22 June 2001 07:10 am Vadim Plessky wrote:
> On Thursday 21 June 2001 23:06 asorensen@ucsd.edu wrote:
> |   Package: kmail
> |   Version: 1.2 (using KDE 2.1.1 )
> |
> |   When I try to send attachments using kmail they almost always
> | get mangled.  PDF files in particular don't seem to be handled
> | correctly.  If I compose a message and attach "test.pdf" (a valid
> | PDF document that I can read just fine using Acrobat) three times
> | using (respectively) 8bit/base64/quoted-printable options the
> | message looks like what I've inserted below.
>
> Hi I experienced similar problem but with text files.
> I  think *easy fix* / hack for you will be to change Chrset to
> iso8859-1 or whatever 8-bit encoding (UTF8 is also ok).
> Looking onto your header:
>    Content-Type: application/pdf;
>      charset=3D"us-ascii";
>      name=3D"test.pdf"
> I guess _charset=3D"us-ascii";_ is causing the problem.
> Isn't it 7-bit encoding?
> BTW: are your PDF files 7-bit encoded?
> You can output PostScript files as7-bit ASCII may be that's was the
> reason while you were able to send PS files.
>
> My problem was in:
>    Content-Type: text/plain;
>      charset=3D"koi8-r";
>      name=3D"mytext_in_cp1251.txt"
>
> mytext_in_cp1251.txt was text file I created in Windows using
> Windows-cp1251 (Cyrillic) encoding.
> THIS PROBLEM CAN'T BE REPRODUCED IF RECEIVER HAS KMAIL.
> You need to send this message to user with MS Outlook
> (I think both Outlook and Outlook 2000 are affected) or open it in
> your Windows.
>
> What Outlook was doing/ *thinking*:
> 1) I received text in koi8-r
> 2) user has cp1251 system setting/encoding
> 3) he opens the file - ok let's recode it to right encoding.
> After it Outlook was recoding mytext_in_cp1251.txt to _cp1251_
> encoding. But as it was already in cp1251 encoding everything
> became completely messed.
>
> I did study what Netscape Messanger was putting in attachement
> header. Actually it was not putting "charset=3D"koi8-r" at all!
> (the same is MS Outlook)
> I guess such header:
> - - -
>    Content-Type: text/plain;
>      name=3D"mytext_in_cp1251.txt"
> - - -
> is also pretty valid charset=3D is *not required*
>
> So what I did:
> * I saved my message fron KMail/outbox to disk
> * deleted charset=3D"koi8-r"; from message attachement descr. (with
> text editor) * saved it disk as mymsg.eml
> * Opened it with Outlook
>
> Voila!  No problem attachement was opened correctly.
> I hope that this bug can be corrected for KDE 2.2 release (or may
> be even for upcoming KDE 2.2beta1)
>
> |   (note that this is what it looks like _before_ it gets sent...so
> | the problem must be in the encoding?)
> |
> |   If I send text files as attachments they work fine.  I've also
> | been able to send postscript files with some success.
> |
> |   Whether this is a bug or something I'm doing wrong it has been
> | driving me crazy for the past couple of months.  Please help!
> |
> |
> |   From asorensen@ucsd.edu Thu Jun 21 16:02:29 2001
> |   Content-Type: Multipart/Mixed;
> |     charset=3D"us-ascii";
> |     boundary=3D"------------Boundary-00=3D_5OYA16Q2OVHQO96UH12R"
> |   From: Alan Sorensen <asorensen@ucsd.edu>
> |   Organization: UCSD Economics
> |   To: asorensen@ucsd.edu
> |   Subject: testing pdf attachments
> |   Date: Thu 21 Jun 2001 16:02:29 -0700
> |   X-Mailer: KMail [version 1.2]
> |   MIME-Version: 1.0
> |   Message-Id: <0106211602290B.08843@sorensen.ucsd.edu>
> |   Status: RO
> |   X-Status: Q
> |
> |
> |   --------------Boundary-00=3D_5OYA16Q2OVHQO96UH12R
> |   Content-Type: text/plain;
> |     charset=3D"us-ascii"
> |   Content-Transfer-Encoding: quoted-printable
> |
> |   three attachments.  none work.  what's up?
> |
> |
> |   --------------Boundary-00=3D_5OYA16Q2OVHQO96UH12R
> |   Content-Type: application/pdf;
> |     charset=3D"us-ascii";
> |     name=3D"test.pdf"
> |   Content-Transfer-Encoding: 8bit
> |   Content-Disposition: attachment; filename=3D"test.pdf"
> |
> |   %PDF-1.2
> |   %=C7=EC?=A2
> |   4 0 obj
> |   <</Length 5 0 R/Filter /FlateDecode>>
> |   stream
> |   x?3=D03T0
> |   --------------Boundary-00=3D_5OYA16Q2OVHQO96UH12R
> |   Content-Type: application/pdf;
> |     charset=3D"us-ascii";
> |     name=3D"test.pdf"
> |   Content-Transfer-Encoding: base64
> |   Content-Disposition: attachment; filename=3D"test.pdf"

On Friday 22 June 2001 16:10 Vadim Plessky wrote:
<snip>
> Hi I experienced similar problem but with text files.
> I  think *easy fix* / hack for you will be to change Chrset to
> iso8859-1 or whatever 8-bit encoding (UTF8 is also ok).
> Looking onto your header:
>    Content-Type: application/pdf;
>      charset="us-ascii";
>      name="test.pdf"
> I guess _charset="us-ascii";_ is causing the problem.
> Isn't it 7-bit encoding?
<snip>

"charset" and "encoding" are two different things in MIME. Typically 
you can freely mix them e.g. QP-encoded UTF8 or BASE64-encoded latin1.

"charset" is a parameter to the "text" mimetype (all subtypes). It 
shouldn't be present for "application" mimetypes.

The way I interpret RFC2046 p.10 par.8

--BEGIN--
   The "charset" parameter has been defined primarily for the purpose of
   textual data and is described in this section for that reason.
   However it is conceivable that non-textual data might also wish to
   specify a charset value for some purpose in which case the same
   syntax and values should be used.
---END---

adding a "charset" parameter to non "text" mimetypes is only 
permissible if the definition of the given mimetype/subtype defines 
it's semantics.

So I guess it's really KMail/mimelib's fault.

<looking at the code>

Um someone did fix it already (still running "old" KMail from a few 
days back)?

kmcomposewin.cpp:1544:
if (msgPart->typeStr().lower() != "text")
  msgPart->setCharset(QCString());

Marc

-- 
Marc Mutz <Marc@Mutz.com>
http://marc.mutz.com/
http://www.mathematik.uni-bielefeld.de/~mmutz/
http://EncryptionHOWTO.sourceforge.net/

On Friday 22. June 2001 18:20 Alan Sorensen wrote:
>
> In fact after looking at the problem more closely it really seems
> like the problem is in the encoding.  As a stark example I tried
> sending the same large PDF file (a 40-page academic article) from
> Eudora (Windows) and Kmail using base64 encoding.  (The Eudora
> attachment works fine the kmail attachment doesn't.)  Looking at my
> ~/Mail/inbox file the attachment in the Eudora message is many hundred
> lines of garbled text; the message from kmail is exactly two lines of
> garbled text.  Those first two lines precisely match the first two
> lines of the Eudora attachment so it's starting out OK....but why is
> it cutting off the file?

The only explanation for a cutted file I have is that it was at least 
temporarily encoded 8-bit in the mail. In this case it is truncated on the 
first ^@ character.
Is base64 already selected in the attachment dialog when you try to attach 
that file?

Regards
Michael Häckel

On Friday 22. June 2001 16:10 Vadim Plessky wrote:
>
> Hi I experienced similar problem but with text files.
> I  think *easy fix* / hack for you will be to change Chrset to iso8859-1 or
> whatever 8-bit encoding (UTF8 is also ok).
> Looking onto your header:
>    Content-Type: application/pdf;
>      charset="us-ascii";
>      name="test.pdf"

This problem is already fixed.

> My problem was in:
>    Content-Type: text/plain;
>      charset="koi8-r";
>      name="mytext_in_cp1251.txt"

All text attachments currently get the charset header you select in the menu.

> I did study what Netscape Messanger was putting in attachement header.
> Actually it was not putting "charset="koi8-r" at all!
> (the same is MS Outlook)
> I guess such header:
> - - -
>    Content-Type: text/plain;
>      name="mytext_in_cp1251.txt"
> - - -
> is also pretty valid charset= is *not required*

No this is pretty invalid according to RFC2045 at least if your text 
contains russian characters.
If there is no charset header in a text part then it means us-ascii and I 
guess that is not what you want.

Use application/octet-stream if you don't want to have it recognized as text.

Regards
Michael Häckel

On Sunday 24 June 2001 18:26 Michael H=E4ckel wrote:
|   On Friday 22. June 2001 16:10 Vadim Plessky wrote:
|   > Hi I experienced similar problem but with text files.
|   > I  think *easy fix* / hack for you will be to change Chrset to
|   > iso8859-1 or whatever 8-bit encoding (UTF8 is also ok).
|   > Looking onto your header:
|   >    Content-Type: application/pdf;
|   >      charset=3D"us-ascii";
|   >      name=3D"test.pdf"
|
|   This problem is already fixed.

Ok.
|
|   > My problem was in:
|   >    Content-Type: text/plain;
|   >      charset=3D"koi8-r";
|   >      name=3D"mytext_in_cp1251.txt"
|
|   All text attachments currently get the charset header you select in the
| menu.

Ok thanks.
Can you please add "cp1251 (Windows Cyrillic)" encoding to KMail's Composer=
=20
Encoding list? Konqueror has it and KMail - missing.
I haven't wrote bug report after KDE 2.1 release as I couldn't test Russia=
n=20
properly with KDE 2.1 anyway.
Now I can and cp1251 is clearly *missing*.  Problem I described above=20
appeared when I was sending cp1251 (Windows) text file.
I don't see how I can encode it properly with KMail if I don't have cp1251=
=20
as an option.

// IDEA:  for text/plain extra option "Encoding/Charset".

|
|   > I did study what Netscape Messanger was putting in attachement header.
|   > Actually it was not putting "charset=3D"koi8-r" at all!
|   > (the same is MS Outlook)
|   > I guess such header:
|   > - - -
|   >    Content-Type: text/plain;
|   >      name=3D"mytext_in_cp1251.txt"
|   > - - -
|   > is also pretty valid charset=3D is *not required*
|
|   No this is pretty invalid according to RFC2045 at least if your text
|   contains russian characters.
|   If there is no charset header in a text part then it means us-ascii and
| I guess that is not what you want.

Yes that's not what I want.
And it means: *both* Netscape Messanger and MS Outlook are buggy in this=
=20
case. They do not put "charset=3D..." on attachement when send it.=20=20
// both were tested by me under Windows. don't know about Netscape Messange=
r=20
on Linux as I don't use it at all.=20

|
|   Use application/octet-stream if you don't want to have it recognized as
| text.

But is it possible to *fake* mail client in this way?
I guess if MS Outllok receives "application/octet-stream" attachement it=
=20
will treat it as .exe file or something like that.
I also afraid that some Virus-filter installed on Exchange server or=20
locally will "cut off" such kind of attachement.
=20
|
|   Regards
|   Michael H=E4ckel

Thanks for your help!
--=20

Vadim Plessky
http://kde2.newmail.ru  (English)
33 Window Decorations and 6 Widget Styles for KDE
http://kde2.newmail.ru/kde_themes.html
Do you have Arial font installed? Just test it!
http://kde2.newmail.ru/font_test_arial.html

>
> The only explanation for a cutted file I have is that it was at
> least temporarily encoded 8-bit in the mail. In this case it is
> truncated on the first ^@ character.
> Is base64 already selected in the attachment dialog when you try to
> attach that file?
>

No.  The attachment dialog comes up with "none (8bit)" as the default.  
If I choose the "none (8bit)" option here's what the attachment looks 
like:

--------------Boundary-00=_RORH252V2LZZC9VU2LPQ
Content-Type: application/pdf;
  charset="iso-8859-1";
  name="benkard.pdf"
Content-Transfer-Encoding: 8bit
Content-Disposition: attachment; filename="benkard.pdf"

%PDF-1.2
%âãÃÃ
2 0 obj
<<
/Length 2935
/Filter /FlateDecode
>>
stream
HÂtWÃrãÃ}ÃWð±ÂÃè[ÃÃvìL*N¹<Jòàä!
°
--------------Boundary-00=_RORH252V2LZZC9VU2LPQ--

Again to me it looks like it must have been truncated since this is a 
relatively large PDF file.

Also it doesn't seem to matter whether I choose "Allow 8-bit" or "MIME 
Compliant (Quoted Printable)" in the 
Settings->Configuration->Network->Properties dialog.

Still perplexed

Alan

On Monday 25. June 2001 17:20 Alan Sorensen wrote:
> > The only explanation for a cutted file I have is that it was at
> > least temporarily encoded 8-bit in the mail. In this case it is
> > truncated on the first ^@ character.
> > Is base64 already selected in the attachment dialog when you try to
> > attach that file?
>
> No.  The attachment dialog comes up with "none (8bit)" as the default.
> If I choose the "none (8bit)" option here's what the attachment looks
> like:

I still think that this is the problem then because the attachment is 
already encoded internally this way.

Does it help if you remove the line "encoding=8bit" from 
~/.kde/share/config/kmailrc ?

This is an upgrading problem you most likely were running KDE 1.x in the 
same directory.
I just removed the code that reads this information at all since base64 
should always be the default.

> Again to me it looks like it must have been truncated since this is a
> relatively large PDF file.
>
> Also it doesn't seem to matter whether I choose "Allow 8-bit" or "MIME
> Compliant (Quoted Printable)" in the
> Settings->Configuration->Network->Properties dialog.

This setting is for the message text and not for attachments.

Regards
Michael Häckel

On Monday 25 June 2001 09:33 am you wrote:
> On Monday 25. June 2001 17:20 Alan Sorensen wrote:
> > > The only explanation for a cutted file I have is that it was at
> > > least temporarily encoded 8-bit in the mail. In this case it is
> > > truncated on the first ^@ character.
> > > Is base64 already selected in the attachment dialog when you try
> > > to attach that file?
> >
> > No.  The attachment dialog comes up with "none (8bit)" as the
> > default. If I choose the "none (8bit)" option here's what the
> > attachment looks like:
>
> I still think that this is the problem then because the attachment
> is already encoded internally this way.
>
> Does it help if you remove the line "encoding=8bit" from
> ~/.kde/share/config/kmailrc ?

Yes!  I removed two lines from my kmailrc file:  one had 
"encoding=ignored" in the [Composer] section the other had "encoding=" 
in the [General] section.  Now the attachments work fine.

>
> This is an upgrading problem you most likely were running KDE 1.x in
> the same directory.
> I just removed the code that reads this information at all since
> base64 should always be the default.
>

I think you're right about this being an upgrading problem.  I didn't 
remove KDE 1.x before installing KDE 2.1 (I installed KDE 2.1 along 
with a RedHat upgrade to 7.1).  If anyone knows how to remove KDE 1.x 
ex post I'd be glad to hear how.

Many thanks!

On Monday 25. June 2001 20:01 Alan Sorensen wrote:
>
> Yes!  I removed two lines from my kmailrc file:  one had
> "encoding=ignored" in the [Composer] section the other had "encoding="
> in the [General] section.  Now the attachments work fine.
>
> > This is an upgrading problem you most likely were running KDE 1.x in
> > the same directory.
> > I just removed the code that reads this information at all since
> > base64 should always be the default.
>
> I think you're right about this being an upgrading problem.  I didn't
> remove KDE 1.x before installing KDE 2.1 (I installed KDE 2.1 along
> with a RedHat upgrade to 7.1).  If anyone knows how to remove KDE 1.x
> ex post I'd be glad to hear how.

rm -rf ~/.kde but you loose also your new setting by doing that.

In general upgrading should of course work without a problem but it is 
usually not tested very well.

Regards
Michael Haeckel