Re: Kmail problems with signed attachments

[David Pye <dmp@davidmpye.dyndns.org>]

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: <200304092326.57514.mika.fischer@zoopnet.de>
> -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