Hmm... I [resume you're aware the ^M characters are actually DOS/Windows carriage returns? ie CRLF, rather than the unix convention of just LF..
David 'On Wednesday 09 April 2003 23:01, Mika Fischer wrote: > Hi! > > [Keeping this on the list because it has something to do with kmail :)] > > So back to my probblem from the "kmail & cryptplug anyone?" thread... > > I ran several tests and this is what I found out: > > 1. The behaviour is different between using the MTA via SMTP or via > /usr/lib/sendmail. I couldn't think of an easy test for the SMTP case > but I figured out what goes on when using /usr/lib/sendmail by > replacing it with a script that logs the message to a file. (So 2. > applies only to /usr/lib/sendmail-mode) > 2. the diff between what kmail stores and kmail sends (!) is: > ----------------------------------------------------------------------- > --- kmail-1-original 2003-04-09 23:27:27.000000000 +0200 > +++ kmail-2-sent-to-mta 2003-04-09 23:27:13.000000000 +0200 > @@ -11,40 +11,35 @@ > charset="us-ascii" > Content-Transfer-Encoding: 7bit > Message-Id: <[EMAIL PROTECTED]> > -Status: RO > -X-Status: S > -X-KMail-EncryptionState: N > -X-KMail-SignatureState: N > > > --Boundary-03=_hAJl+awMqMT+u63 > -Content-Type: multipart/mixed; > - boundary="Boundary-01=_hAJl+ZOWvqRjtRd" > -Content-Transfer-Encoding: 7bit > -Content-Description: signed data > -Content-Disposition: inline > - > - > ---Boundary-01=_hAJl+ZOWvqRjtRd > -Content-Type: text/plain; > - charset="us-ascii" > -Content-Transfer-Encoding: 7bit > -Content-Description: body text > -Content-Disposition: inline > - > -This is a test-mail. > - > ---Boundary-01=_hAJl+ZOWvqRjtRd > -Content-Type: text/plain; > - charset="us-ascii"; > - name="test-attachment" > -Content-Transfer-Encoding: 7bit > -Content-Disposition: attachment; filename="test-attachment" > - > -This is a test-attachment. > - > - > ---Boundary-01=_hAJl+ZOWvqRjtRd-- > +Content-Type: multipart/mixed; > + boundary="Boundary-01=_hAJl+ZOWvqRjtRd" > +Content-Transfer-Encoding: 7bit > +Content-Description: signed data > +Content-Disposition: inline > + > +--Boundary-01=_hAJl+ZOWvqRjtRd > +Content-Type: text/plain; > + charset="us-ascii" > +Content-Transfer-Encoding: 7bit > +Content-Description: body text > +Content-Disposition: inline > + > +This is a test-mail. > + > +--Boundary-01=_hAJl+ZOWvqRjtRd > +Content-Type: text/plain; > + charset="us-ascii"; > + name="test-attachment" > +Content-Transfer-Encoding: 7bit > +Content-Disposition: attachment; filename="test-attachment" > + > +This is a test-attachment. > + > + > +--Boundary-01=_hAJl+ZOWvqRjtRd-- > > --Boundary-03=_hAJl+awMqMT+u63 > Content-Type: application/pgp-signature > ----------------------------------------------------------------------- > > The reason for all the seamingly identical lines is that the original > has a "^M" character at the end of the line. > So with the "^M"s the signature is correct, without it it's not. > Interestingly the "^M"s appear only in the "multipart/mixed" part of > the message (the part that is signed) and not in the rest... > > So that's the reason. I have really no idea why the hell kmail does this > but I'm going to file a bug tomorrow if noone has done so already. > > 3. As if this was not strange enough... here it comes :) > If I send the mail via SMTP to localhost something (after this I'm > really not sure if it is kmail *again*) adds an empty "Subject:" header > to every MIME-part. I've searched the RFCs but found nothing indicating > that such a header was mandatory. > So I'll probably file another bug about this one :) > > I'd be glad if anyone could check all this and get back to me on whether > or not it could be reproduced. > > Cheers, > Mika