problem with signed posts

problem with signed posts

[Richard Riley]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=us-ascii, Size: 7181 bytes --]


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) "Ã\b	
| #‡" [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" "\r\n" t)
|   byte-code("Ælj‰‰‰\x18\x19\x1a^[\x1c\x1dÈ\x0e\x1dÉÊË\x0e\x1d@#†\x1a\0ÌÆ#‰\x11ƒ.\0Í\x0e\x1eAÌÇÆ$‰\x10„R\0\x0e\x1fÎÏ\x1e \x1e!‰\x1e\x1eƒK\0ÐÊ\x0e\x1e@G\x0e!\x0e \x0e\x1e@%ˆ+ÑÒ\x0e\x1e\"ˆÓ	ÔÕÆ$\x11Ö\b!\x10× \x14ÒØُˆ\x0e\x1fÎÚÛ\fÜ\"!\x1e \x1e!‰\x1e\x1eƒ‡\0ÐÊ\x0e\x1e@G\x0e!\x0e \x0e\x1e@%ˆ+\x0e\x1e.\x06‡" [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" "\r\n" mm-get-part epg-make-context (byte-code "Ä\b	\n#\x13ć" [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)
`----