problem with signed posts

[Richard Riley]

Having just moved to a new laptop I now have a problem with signed
messages. When reading one I get (I include it in full) the following. I
guess I have missed a library or setting, but what? Emacs 23 in debian
squeeze.


,----
| Debugger entered--Lisp error: (wrong-number-of-arguments #[(target old new) 
"Ã       
| #‡" [old new target replace-regexp-in-string] 4] 4)
|   mm-replace-in-string("Content-Type: text/plain; charset=US-ASCII\n\nEric 
Schulte wrote:\n>Hi David,\n> [...]\n>>\n>> 2nd/\n>>\n>> The usage of 
multipart/alternative is not in compliance with the\n>> specs, too.  There it 
reads:\n>>\n>> [...]\n>>\n>> So if you attach *only a part* of the plain text 
message body, you\n>> should not use multipart/alternative: Because\n>>\n>>   
1. a part of a message is not \"an 'alternative' version of the same\n>>      
information.\"\n>>\n>>   2. if recipients user agent prefers html messages it 
will display\n>>      only the html'ized part.\n>>\n\n>I should have been 
clearer here.  I *am* using the multipart/alternative\n>appropriately.  When a 
chunk of org-mode text is converted to html I am\n>adding a single 
multipart/alternative block with two alternatives, both\n>the plain org-mode 
text, and the html, so that users like me who prefer\n>to see plain text can do 
so, and users of web clients like gmail can see\n>nice markup.\n\nOkay, should 
have looked closer to the code.\n\n1/\n\nBut I still feel uncomfortable with 
the current solution: Even if the\nmessage created by current org-mail-htmlize 
is a valid MIME message (I\nthink so) it is a rather complex MIME structure and 
I have no idea how\nother MUAs will display such a message.\n\nMoreover, this 
complexity is unecessary if we make the assumption:\n\n  If substantial parts 
of your message require html markup do be\n  displayed by a some of your 
recipients, than send a html\n  representation of the entire message along with 
the plain text.[1]\n\nFor a recipient who preferes html the result is the same: 
For him the\nsubstantial parts are displayed in a meaningful way.  People 
who\nprefer or depend on plain text get the plain text.  And we 
avoid\nuneccesary complexity.\n\nThinking functional this might be the first 
function of\norg-mail-htmlize[1]: Create a html representation of message body 
if\nnecessary or appropriate.\n\n2/\n\nThe second function: Attach external 
files that are referenced in the\nmessage.  This might be useful even if you 
don't send out html\nmessages: All external files are stashed into a 
multipart/mixed\ncontainer along with a Content-Id: header field.\n\nThan all 
references are changed accordingly to point to the attached\nfiles:\n\n  - for 
html use src/href with the cid: prefix\n\n  - for text: good question.  Maybe 
replace occurences of the file\n    with a customizable string saying: \"see 
attached file foo.bar\".\n\n3/\n\nFor Wanderlust multipart/alternative is 
(replace \"_\" by \"-\")\n\n__<<alternative>>_{\n\nand 
closing\n\n__}_<<alternative>>\n\n4/\n\nDetecting the plain text body should 
not just stop on end of buffer\nbut also on the first occurence of a MIME 
delimiter: Maybe the user\nalready added a attachment.\n\nAnd, last not least: 
This has the potential for going into contrib.\nMaybe it should be renamed to 
org-mime -- it's neither just about\nmail, nor just about htmlizing.\n\nHTH\n  
-- David\n\n[1] This assumption may also address the concerns about sending 
html\nmessages: From my perspective html message are not a problem in\nitself.  
Sometimes people have to send html messages (organizational\nrules) and 
sometimes it is appropriate for content to render properly.\nAs far as I read 
on the topic of html message they got their bad name\nbecause people where 
sending html messages implicitely assuming that\nall recipients /can/ read them 
in the same \"fancy\" format as they did.\nSuch an assumtion is wrong because 
it does not take into account that\ninformation and it's representation are two 
different things and\ncomputers are create in processing and (re)formatting 
information.\n\nAnyway, what org-mail-htmlize really misses is a function that 
adds\nfance pictures (cats!), sounds and maybe even flash animations to 
the\nmessages :D\n\n\n\n--\nOpenPGP... 0x99ADB83B5A4478E6\nJabber.... 
dmjena@jabber.org\nEmail..... dmaus@ictsoc.de\n" "\n" "
\n" t)
|   byte-code("Ælj‰‰‰ÈÉÊË@#†ÌÆ#‰ƒ.ÍAÌÇÆ$‰„RÎÏ 
!‰ƒKÐÊ@G! @%ˆ+ÑÒ\"ˆÓ     ÔÕÆ$Ö!× ÒØُˆÎÚÛ\fÜ\"! 
!‰ƒ‡ÐÊ@G! @%ˆ+.‡" [signature part signature-file plain context 
inhibit-redisplay t nil mm-find-raw-part-by-type get-text-property 0 protocol 
"application/pgp-signature" mm-find-part-by-type gnus-info "Corrupted" 
put-text-property throw error mm-replace-in-string "\n" "
\n" mm-get-part epg-make-context (byte-code "Ä \n#ć" [context signature part 
plain epg-verify-string] 4) ((error ...)) epg-verify-result-to-string 
epg-context-result-for verify ctl handle mm-security-handle value parameter] 7)
|   mml2015-epg-verify(((#<buffer  *mm*<3>> ("text/plain" ...) nil nil nil nil 
nil nil) (#<buffer  *mm*<4>> ("application/pgp-signature") 7bit nil nil nil nil 
nil)) (#("multipart/signed" 0 16 (protocol "application/pgp-signature" boundary 
"pgp-sign-Multipart_Wed_Mar_31_22:37:19_2010-1" buffer #<buffer  *mm*<2>> from 
"dmaus@ictsoc.de" start nil)) (protocol . "application/pgp-signature") 
(boundary . "pgp-sign-Multipart_Wed_Mar_31_22:37:19_2010-1")))
|   mml2015-verify(((#<buffer  *mm*<3>> ("text/plain" ...) nil nil nil nil nil 
nil) (#<buffer  *mm*<4>> ("application/pgp-signature") 7bit nil nil nil nil 
nil)) (#("multipart/signed" 0 16 (protocol "application/pgp-signature" boundary 
"pgp-sign-Multipart_Wed_Mar_31_22:37:19_2010-1" buffer #<buffer  *mm*<2>> from 
"dmaus@ictsoc.de" start nil)) (protocol . "application/pgp-signature") 
(boundary . "pgp-sign-Multipart_Wed_Mar_31_22:37:19_2010-1")))
|   mm-possibly-verify-or-decrypt(((#<buffer  *mm*<3>> ("text/plain" ...) nil 
nil nil nil nil nil) (#<buffer  *mm*<4>> ("application/pgp-signature") 7bit nil 
nil nil nil nil)) (#("multipart/signed" 0 16 (protocol 
"application/pgp-signature" boundary 
"pgp-sign-Multipart_Wed_Mar_31_22:37:19_2010-1" buffer #<buffer  *mm*<2>> from 
"dmaus@ictsoc.de" start nil)) (protocol . "application/pgp-signature") 
(boundary . "pgp-sign-Multipart_Wed_Mar_31_22:37:19_2010-1")))
|   mm-dissect-multipart((#("multipart/signed" 0 16 (protocol 
"application/pgp-signature" boundary 
"pgp-sign-Multipart_Wed_Mar_31_22:37:19_2010-1" buffer #<buffer  *mm*<2>> from 
"dmaus@ictsoc.de" start nil)) (protocol . "application/pgp-signature") 
(boundary . "pgp-sign-Multipart_Wed_Mar_31_22:37:19_2010-1")) "dmaus@ictsoc.de")
|   mm-dissect-buffer(t nil "dmaus@ictsoc.de")
|   mm-dissect-multipart((#("multipart/mixed" 0 15 (boundary 
"===============1410124565==" buffer #<buffer  *mm*> from "dmaus@ictsoc.de" 
start nil)) (boundary . "===============1410124565==")) "dmaus@ictsoc.de")
|   mm-dissect-buffer(nil t)
|   gnus-display-mime()
|   gnus-article-prepare-display()
|   gnus-article-prepare(613 nil)
|   gnus-summary-display-article(613)
|   gnus-summary-next-page(nil)
|   call-interactively(gnus-summary-next-page nil nil)
`----