Re: Kmail problems with signed attachments
On Thu, Apr 10, 2003 at 01:34:29AM +0200, Mika Fischer wrote: Hi, David! On Thursday 10 April 2003 01:29, David Pye wrote: I [resume you're aware the ^M characters are actually DOS/Windows carriage returns? ie CRLF, rather than the unix convention of just LF.. Yes, I know :) I just can't think of a reason why kmail would put them in there (only in the signed part) then sign the message and then remov them again befor sending the mail out :) It just doesn't make any sense... Because that's the way the RFC says you have to... I've made a simple signing bot using Python/Pyme for some tasks inside my LUG, and I were utterly failing for a couple of hours until I re-read carefully the RFC and saw that reference to CRLF.
Re: Kmail problems with signed attachments
Hi, Ricardo! On Thursday 10 April 2003 11:12, Ricardo Javier Cardenes Medina wrote: I just can't think of a reason why kmail would put them in there (only in the signed part) then sign the message and then remov them again befor sending the mail out :) It just doesn't make any sense... Because that's the way the RFC says you have to... I've made a simple signing bot using Python/Pyme for some tasks inside my LUG, and I were utterly failing for a couple of hours until I re-read carefully the RFC and saw that reference to CRLF. I guess you mean: that kmail puts the CRs in for signing is good, but that it removes them again before sending is not :) I can live with that. But as it is now, every signd mail with an attachment will have its signature damaged even before it leaves kmail... But anyway can you tell me which RFC you're referring to? In 1847 I couldn't find anything like that... And, as a side note: mutt puts no CRs in... :) Cheers, Mika pgpsUfMARccwo.pgp Description: signature
Re: Kmail problems with signed attachments
On Thu, Apr 10, 2003 at 07:30:20PM +0200, Mika Fischer wrote: I guess you mean: that kmail puts the CRs in for signing is good, but that it removes them again before sending is not :) Mmh... Now that you say it, I should review it a bit. Probably Python's SMTP module is CR'cing the message before sending it. I'll tell you... I can live with that. But as it is now, every signd mail with an attachment will have its signature damaged even before it leaves kmail... But anyway can you tell me which RFC you're referring to? In 1847 I couldn't find anything like that... RFC 2015: MIME Security with Pretty Good Privacy (PGP) Quote: When the PGP digital signature is generated: (1) The data to be signed must first be converted to its type/subtype specific canonical form. For text/plain, this means conversion to an appropriate character set and conversion of line endings to the canonical CRLF sequence. (2) An appropriate Content-Transfer-Encoding is then applied. Each line of the encoded data MUST end with the canonical CRLF sequence. (3) MIME content headers are then added to the body, each ending with the canonical CRLF sequence. (4) As described in [1], the digital signature MUST be calculated over both the data to be signed and its set of content headers. (5) The signature MUST be generated detached from the signed data so that the process does not alter the signed data in any way. ... [1] Galvin, J., Murphy, G., Crocker, S., and N. Freed, Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted, RFC 1847, October 1995. And, as a side note: mutt puts no CRs in... :) Cheers, Mika
Re: Kmail problems with signed attachments
I wonder if this is what happens: I *know* in transit some of the CRs may get turned into CRLFs (Can't confirm when tho!) and therefore KMail assumes that this is certain to happen, and therefore signs the message with them in to ensure that things will match ok? David On Thursday 10 April 2003 18:30, Mika Fischer wrote: Hi, Ricardo! On Thursday 10 April 2003 11:12, Ricardo Javier Cardenes Medina wrote: I just can't think of a reason why kmail would put them in there (only in the signed part) then sign the message and then remov them again befor sending the mail out :) It just doesn't make any sense... Because that's the way the RFC says you have to... I've made a simple signing bot using Python/Pyme for some tasks inside my LUG, and I were utterly failing for a couple of hours until I re-read carefully the RFC and saw that reference to CRLF. I guess you mean: that kmail puts the CRs in for signing is good, but that it removes them again before sending is not :) I can live with that. But as it is now, every signd mail with an attachment will have its signature damaged even before it leaves kmail... But anyway can you tell me which RFC you're referring to? In 1847 I couldn't find anything like that... And, as a side note: mutt puts no CRs in... :) Cheers, Mika
Re: Kmail problems with signed attachments
Hi, David! On Thursday 10 April 2003 21:30, David Pye wrote: I wonder if this is what happens: I *know* in transit some of the CRs may get turned into CRLFs (Can't confirm when tho!) and therefore KMail assumes that this is certain to happen, and therefore signs the message with them in to ensure that things will match ok? May well be the reasoning behind this. I filed a bug (http://bugs.kde.org/show_bug.cgi?id=57098). Let's see what the kmail guys say about it. Cheers, Mika pgpnJUGVLNFGg.pgp Description: signature
Re: Kmail problems with signed attachments
Hi, Ricardo! On Thursday 10 April 2003 21:04, Ricardo Javier Cardenes Medina wrote: On Thu, Apr 10, 2003 at 07:30:20PM +0200, Mika Fischer wrote: I guess you mean: that kmail puts the CRs in for signing is good, but that it removes them again before sending is not :) Mmh... Now that you say it, I should review it a bit. Probably Python's SMTP module is CR'cing the message before sending it. I'll tell you... All I wanted to say is that kmail *changes* the signed content of messages. And that can't be good :) RFC 2015: MIME Security with Pretty Good Privacy (PGP) Thanks. The newer one is 3156, BTW. But it has exacty the same list... And, as a side note: mutt puts no CRs in... :) Leaves the question, why doesn't mutt do it. But I guess that's a bit off-topic here... :) Cheers, Mika pgpGablDqWYBK.pgp Description: signature
Kmail problems with signed attachments
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-original2003-04-09 23:27:27.0 +0200 +++ kmail-2-sent-to-mta 2003-04-09 23:27:13.0 +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 ^Ms the signature is correct, without it it's not. Interestingly the ^Ms 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 pgp7KjrBRPkEL.pgp Description: signature
Re: Kmail problems with signed attachments
Hi! Small addition... On Thursday 10 April 2003 00:01, Mika Fischer wrote: 1. The behaviour is different between using the MTA via SMTP or via /usr/lib/sendmail. This is wrong. The behaviour is actually the same. 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 :) This is really kmail. When first displaying the message it adds those headers itself which is totally crazy :) So, filing two bugs tomorrow :) Cheers, Mika pgpeZnzxxe1oM.pgp Description: signature
Re: Kmail problems with signed attachments
Hi, David! On Thursday 10 April 2003 01:29, David Pye wrote: I [resume you're aware the ^M characters are actually DOS/Windows carriage returns? ie CRLF, rather than the unix convention of just LF.. Yes, I know :) I just can't think of a reason why kmail would put them in there (only in the signed part) then sign the message and then remov them again befor sending the mail out :) It just doesn't make any sense... Cheers, Mika pgpfFBMg99ULE.pgp Description: signature
Re: Kmail problems with signed attachments
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-original2003-04-09 23:27:27.0 +0200 +++ kmail-2-sent-to-mta 2003-04-09 23:27:13.0 +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 ^Ms the signature is correct, without it it's not. Interestingly the ^Ms 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
