Created attachment 2164 [details] Patch for review Dear all, For various reasons I regularly receive PGP/MIME messages, which include protected headers. Claws Mail with PGP/MIME display these headers in front of the message and wastes a lot of screen space. I created a patch to a) suppress the display of these headers by exceptional handling in textview/..add_parttextview/..add_part b) prepare adding the headers to the msginfo->extradata for later processing (e.g. matching with current headers. Please see attached patch, review and consider to apply or provide feedback on improving it.
Created attachment 2165 [details] Proposed patch revised to apply with -p0 to current git head
actually, not in the PGP component, but in the core.
can you provide an example message?
Created attachment 2166 [details] Example document structure Hi Paul, thanks for responding quickly, I have attached an email skeleton, as I am receiving it. It seems to be created compliant to the IETF draft mentioned in Bug#3904. Section 5.1 of that document recommends to use "Dispiosition: inline" in order to encourage clients to render it. However, I guess there are more efficient ways to display header related information than dumping it in front of the message body, which, that's acknowledged, is a valid interpretation.
Ah, one more: I could make you receive such an email on your account. I have been looking for your PGP key on https://keys.openpgp.org, https://keyserver.pgp.com/, and https://pgp.mit.edu. Could you send my your pubkey for that or tell me which keyserver to use?
use the key id found here: https://www.claws-mail.org/theteam.php it's on https://keys.openpgp.org/
Dear Paul, Finally, I was able to download your key from keys.openpgp.org. Hoewever I cannot import it into gpg as the known problem of gnupg kicks in: key 2CD716D654D6BBD4: new key but contains no user ID - skipped I will resume this activity as soon as I get the gpg issue resolved. Meanwhile, I have found a nasty flaw in Firefox/Enigmail: when using PGP/MIME, it emits the protected headers in the preamble (see below), which is contrasting - RFC 1521 7.2.1, which states: "This is the preamble. It is to be ignored, though it is a handy place for mail composers to include an explanatory note to non-MIME conformant readers." - and RFC 2046 5.1.1:"These areas should generally be left blank, and implementations must ignore anything that appears before the first boundary delimiter line or after the last one." Is this the behavior, you consider as "violating standards"? I tend to agree. --------(Example generated by Firefox/Enigmail) Content-Type: multipart/mixed; boundary="hXnaK4414ZzLRm6Y6kgUXOBJeTUVutMqB"; protected-headers="v1" <Protected headers here> --hXnaK4414ZzLRm6Y6kgUXOBJeTUVutMqB Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: de-DE <Mail body here> --------- The IETF draft which In mentioned before, at least seems to circumvent these standard violations by introducing a new MIME-subtype to hold the protected headers.
Any news on this? You can get my key using WKD.
As you have been asking for the status: my apologies for not having updated the request for a while. a) I have not received any response from Daniel Gilmor in regard to the IETF draft. What a pity. Maybe he has lost his interest in the matter. b) I have been working on making my patch work without side effects. There were still bugs popping up and I had to start over, also because diue to the structure of my previous work I had issues in repreatedly rebasing my patch to master/head. c) I now have a version working with the IETF-approach, but not yet with the Thunderbird/enigmail or native thuderbird approach. This is my next endeavour. d) In regard to providing a test message please stay tuned...
Created attachment 2256 [details] proposed patch for ietf draft approach (not thunderbird/enigmail) find attached patch proposal which applies to, and allows to process protected headers according to IETF draft. https://git.claws-mail.org/?p=claws.git;a=commit;h=71e1e70a4720985cd86324afd45e6ef08e5b4cf1 Example messages are also attached.
Created attachment 2257 [details] email used as input to the header protection procedure Find attached the (standard) email used as input for the header protection.
Created attachment 2258 [details] email sent to the resipient (encrypted for p***@****.***) find attached the email as it would be sent in an encrypted for p***@***.***
Created attachment 2259 [details] email sent to the recipient (decrypted) find attached the email structure after decryption.
Thanks for the patch!, it compiles fine for me but as I have got only "enigmail"-like Emails with protected headers I could not test in "real life", looking forward!
I get on the terminal occasional `procheader.c:293 Condition harray != NULL failed` and then a traceback. Do you need debugging information for this?
Thanks, Felix, for reporting this. I don't think I'll need more debugging information. Will provide a fix soon.
Created attachment 2260 [details] revised patch. warnings should no longer be printed. did revise the patch. Was originally tolerating to call the destroy function for header arrays unconditionally (potentially with a NULL argument). Moved the call inside of the block where argument is not NULL.
@claws-mail-devel@nopicturesplease.de: Is git://github.com/ahngoo8Gongi/claws-mail/tree/protected-headers.git the same as git://git.claws-mail.org/claws.git with the applied latest patch?
I have made an Arch Linux package with that patch, and I am about to keep it up to date: http://aur.archlinux.org/packages/claws-mail-gtk2-protectedheaders-nonm-git/
Dear Felix, actually you found (almost) the right place. The current patch is on https://github.com/ahngoo8Gongi/claws-mail/tree/protected-headers-21 the one you found is the one which I couldn't successfully rebase to main. I'm also trying to follow the main git repo of claws mail there. And, btw, thanks for creating and updating the arch Linux package. Keeps me reminded of my todo to also support the enigmail stuff. but it may take some more days - as I'll have some other business that needs to be done first...
The patch from 2021-11-08 does not apply anymore. So I switch to https://github.com/ahngoo8Gongi/claws-mail/tree/protected-headers-21 now.
(In reply to linux.felixbecker2 from comment #21) > The patch from 2021-11-08 does not apply anymore. So I switch to > https://github.com/ahngoo8Gongi/claws-mail/tree/protected-headers-21 now. .. which fails to build for me: ``` [...] /bin/sh ../../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I../.. -I../../intl -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -pthread -DLOCALEDIR=\""/usr/share/locale"\" -DPLUGINDIR=\"/usr/lib/claws-mail/plugins/\" -DDATAROOTDIR=\""/usr/share"\" -DDESKTOPFILEPATH=\"/usr/share/applications/claws-mail.desktop\" -DGTK_DISABLE_DEPRECATED -Wall -Wno-pointer-sign -g0 -march=x86-64 -mtune=native -O3 -pipe -fstack-protector --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2 -fomit-frame-pointer -fPIC -MT xmlprops.lo -MD -MP -MF .deps/xmlprops.Tpo -c -o xmlprops.lo xmlprops.c In file included from claws.c:42: claws.c: In function ‘claws_get_version’: version.h:32:54: error: invalid suffix "c0ef3" on integer constant 32 | #define VERSION_NUMERIC MAKE_NUMERIC_VERSION(8c0ef3, 8c0ef3, \ | ^~~~~~ version.h:25:54: note: in definition of macro ‘MAKE_NUMERIC_VERSION’ 25 | #define MAKE_NUMERIC_VERSION(a, b, c, d) ((((guint32)a) << 24) | (((guint32)b) << 16) | \ | ^ claws.c:143:16: note: in expansion of macro ‘VERSION_NUMERIC’ 143 | return VERSION_NUMERIC; | ^~~~~~~~~~~~~~~ version.h:32:62: error: invalid suffix "c0ef3" on integer constant 32 | #define VERSION_NUMERIC MAKE_NUMERIC_VERSION(8c0ef3, 8c0ef3, \ | ^~~~~~ version.h:25:77: note: in definition of macro ‘MAKE_NUMERIC_VERSION’ 25 | #define MAKE_NUMERIC_VERSION(a, b, c, d) ((((guint32)a) << 24) | (((guint32)b) << 16) | \ | ^ claws.c:143:16: note: in expansion of macro ‘VERSION_NUMERIC’ 143 | return VERSION_NUMERIC; | ^~~~~~~~~~~~~~~ version.h:33:54: error: invalid suffix "c0ef3" on integer constant 33 | 8c0ef3, 0) | ^~~~~~ version.h:26:54: note: in definition of macro ‘MAKE_NUMERIC_VERSION’ 26 | (((guint32)c) << 8) | ((guint32)d) ) | ^ claws.c:143:16: note: in expansion of macro ‘VERSION_NUMERIC’ 143 | return VERSION_NUMERIC; | ^~~~~~~~~~~~~~~ claws.c:144:1: warning: control reaches end of non-void function [-Wreturn-type] 144 | } | ^ libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../.. -I../../intl -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -pthread -DLOCALEDIR=\"/usr/share/locale\" -DPLUGINDIR=\"/usr/lib/claws-mail/plugins/\" -DDATAROOTDIR=\"/usr/share\" -DDESKTOPFILEPATH=\"/usr/share/applications/claws-mail.desktop\" -DGTK_DISABLE_DEPRECATED -Wall -Wno-pointer-sign -g0 -march=x86-64 -mtune=native -O3 -pipe -fstack-protector --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2 -fomit-frame-pointer -fPIC -MT xmlprops.lo -MD -MP -MF .deps/xmlprops.Tpo -c xmlprops.c -fPIC -DPIC -o .libs/xmlprops.o make[5]: *** [Makefile:762: claws.lo] Error 1 make[5]: *** Waiting for unfinished jobs.... [...] ```
Dear Felix, that was already an issue on Bug 3904. It looks like version.h has not been built correctly during configure. Does it build well, after you revert my patch? ...after a make distclean/configure?
> It looks like version.h has not been built correctly during configure. I do the following steps to start with a clean source: ``` rm -Rf claws-mail-protectedheaders git clone git://github.com/ahngoo8Gongi/claws-mail.git claws-mail-protectedheaders cd claws-mail-protectedheaders git checkout protected-headers-21 NOCONFIGURE=1 ./autogen.sh ./configure ``` That `./configure` call creates a file `src/common/version.h` which contains the line ``` #define VERSION "8c0ef3.8c0ef3.8c0ef3" ``` (And that `8c0ef3` corresponds to the latest git commit hash: This are the first 6 characters of the output of `git rev-parse --short HEAD`). > Does it build well, after [..] a make distclean/configure? After a `make distclean` that `src/common/version.h` is gone, but `./configure` recreates it. Even if I pass no further arguments to `./configure`, that `src/common/version.h` gets created with the problematic `#define VERSION` line. `make` then fails on it with `version.h:32:54: error: invalid suffix "c0ef3" on integer constant`. > Does it build well, after you revert my patch? If I use as source git://github.com/ahngoo8Gongi/claws-mail.git but with the master branch, `src/common/version.h` gets generated wrongly as well. Also if I use the branch protected-headers-21 and then manually reverse-apply the patch https://www.thewildbeast.co.uk/claws-mail/bugzilla/attachment.cgi?id=2260, `src/common/version.h` gets generated wrongly (the problematic line then even reads `#define VERSION "8c0ef3-dirty.8c0ef3-dirty.8c0ef3"`). If I directly use git://git.claws-mail.org/claws.git as source, `src/common/version.h` gets generated correctly: ``` #define VERSION "3.18.0git297" ``` Could it be that `./configure` needs the data that also `git describe --tags` uses? In your git repo, `git describe --tags` fails with `fatal: No names found, cannot describe anything.`, but in the official repo it outputs `3.18.0-297-g32bc9be42`.
Hey guys, This bug tracker is for the official Claws Mail builds. Try https://github.com/ahngoo8Gongi/claws-mail/issues instead. Thanks!
> Try https://github.com/ahngoo8Gongi/claws-mail/issues instead. For your information: It is now reported at https://github.com/ahngoo8Gongi/claws-mail/issues/3.
*** Bug 3904 has been marked as a duplicate of this bug. ***
Any progress in adding protected headers support for enigmail flavour and properly integrating it into official claws mail?
Is it now a defined standard?
> Is it now a defined standard? I don't know. And I don't know what qualifies for "defined", i.e. which institution has the authority (I don't see that even "RFC"s are authorative in a legal sense, they are just "standards" because many people and projects treat them as such). Is that the requirement? It is at least a "de-facto-standard", since lots of people who use OpenPGP encrypted emails send emails this way, and I see no reason to not create interoperability. You can also frame it "workaround" or whatever if you are not fine with framing it "adhering to a standard"-
.. even mutt can do this, as far as I know from other people (I don't know if it is done via some third-party code, though).
Felix, (Re: https://github.com/ahngoo8Gongi/claws-mail/issues/4#issuecomment-1435647458), you sound annoyed, yes. But you are reading far too much into a simple 6 word question.
> (Re: https://github.com/ahngoo8Gongi/claws-mail/issues/4#issuecomment-1435647458), you sound annoyed, yes. But you are reading far too much into a simple 6 word question. OK, thanks for mentioning that I drew the wrong conclusions, I now corrected the comment. So can you tell how "Is it now a defined standard" affects this issue? Regards!
Dear Paul, the RFC draft originally submitted by D. Gilmore (as referred to by related bug https://www.thewildbeast.co.uk/claws-mail/bugzilla/show_bug.cgi?id=3904#c3) is no longer available on the IETF page. Btw - it had expired already, when I referred to it, back then. Meanwhile I did ask D. Gilmore for backing information about the status - no response. Current status looks like: - no standard seems "broken" literally, - some clients have implemented a non-standard extension, - people using claws-mail have difficulties communicating with such clients. My vote would be: follow the "be strict what you send, be tolerant in what you accept!" paradigm. Personally, I will only resume moving patches forward or backporting stuff to the gtk2 branch, after a decision has been made whether it will be included. Regards, Holger
If a patch against current GTK3 git can be attached, I will apply it to git and get this finally sorted. Thanks in advance.
Dear Paul, thanks for resuming this. Just for my confirmation and efficiency - are you referring to current branch "gtk3" which apparently was not updated for 14 months or "master"?
"master" of course. (The old "master" became the "gtk2" branch and the "gtk3" branch became "master".)
Great info, thanks. I'll start working on it.
Created attachment 2331 [details] forwarded patch to origin/master Please find attached a revised patch, that applies to commit b63e9ce (https://git.claws-mail.org/?p=claws.git;a=commit;h=b63e9ce422a818f5f6b60bb24aa4c30e994d7c75) Protected patch functionality has been verified against: - mail with protected headers in separate mime-part sent by my custom sender. - mail with protected headers in preamble sent using K9-Mail for Android. - mail with protected headers in preamble sent using legacy Thunderbird/Enigmail. - mail with protected headers in preamble sent using new Thunderbird (with GPG support). - encrypted mail without protected headers as generated by claws-mail. - unencrypted mail without protected headers, as sent by a mailing list. Hope it works a good in your environments as in mine.... Please validate and apply at your convenience. In case of any issues, don't hesitate to get in touch with me via this bugzilla.
A cursory glance suggests your patch at least has some rough edges to work out, e.g. around textview_verify_protected_header() and '#define HEADER_NOT_VERIFIED -(i+1)'
Dear Paul, to get out of a "this is bad, retry and come back!" mode, could you kindly elaborate on the "rough edges" that are not obvious to me. Are you just disturbed by the implementation using #define, or more general by the combined implicit encoding of the header index and verification?
like I said, it was a cursory glance (and still is), but, for example, HEADER_NOT_VERIFIED is defined but never used.
Also, why is the header background color modified, under all circumstances?
BTW if you're introducing new color handling, all colors should be made customizable, as hidden options or not (this should be discussed).
Changing the background colour is absolutely not necessary and not wanted, IMO.
Thanks for guiding me to the "roughness" - apparently a flaw, that I overlooked after reworking the patch couple of times...my apologies. Will change that in the next revision. Understood, that modifying the background color is not the preferred way to indicate integrity or falsification of a protected header. Actually, I'm not a UX/design expert, but I'd consider some tagging reasonable to display, whether a message has been tampered with. What would be the claws-mail preferred way to display whether the protected header is identical to the unprotected header from the message header? a) Just display the protected header (if present), and ignore the presence of the unprotected header? b) Display both headers and indicate "protection" in a textual way? E.g. Prefixing the original header with "X-Original-"? c) Use some color coding in the foreground? d) Any other option?
Must admit that I don't have an optinion yet about your questions, but my concern was that absolutely all headers (and attachment parts, in-body) of all emails are showing an altered background color, this is not just about coloring in order to indicate integrity or falsification of a protected header.
@wwp: Ah, got that! You are right. Actually, I added the "background-rgba" tag to the default style, just for symmetry reasons. No problem to leave it off. At least for me, having nothing configured manually, nothing changes by that....(see the two images I attached) Another question in regard to configurability: I couldn't figure out, how the other colors declared in textview.c (e.g. quote_color) are configured...any place where I could look at as an example?
Created attachment 2332 [details] Display on MY system of a mail sent with claws-mail (without protected headers)
Created attachment 2333 [details] Display on MY system of a mail including protected headers
OK. Other colors are declared at the beginning of textview.c, initialized from thepreferences data structure in textview_update_message_colors(). This also means that those colors are declared in the prefs_common.color array. See prefs_message_colors.[ch] and prefs_common.[ch] (check the ColorIndex enum in the .h to start understanding), this is where all this happen. From a GUI perspective, see Configuration >> Preferences >> Display >> Color >> Other.
I think that if coloring is done, it must be an option to enable in the prefs, and colors should be configurable. *For instance*, the default behaviour could be that only suspicious headers are emphasized with color (also think that they are dark and light GTK themes, your colors will not fit my tastes and my theme!) but one may change this and set the colors you show in your screenshots.
In regard to your proposal of a default behavior: We have three cases: 1) no protected header present (default): This IMHO should look like today without any emphasis. 2) protected header present and equal to unprotected headers: We can get along with simply displaying a single header. But how to emphasize that headers were protected and not tampered with? Color (foreground or background), font or typeface? 3) protected header present and different from unprotected header: a) We can get along with simply displaying a single header. We might lose information about the unprotected header, going this way. Are there legitimate use cases, to modify the unprotected header? e.g. forwarding, mailinglists, etc.? The displayed header should be the protected header, shouldn't it? But how to emphasize that the header was tampered with? Color (foreground or background), font or typeface? b) We can chose to display both headers to expose the modification. But how to distinguish the protected and unprotected header? Color (foreground or background), font or typeface? For case 3, I originally prefer 3b) I've chosen color coding, as colors are somehow obviously meaningful, in contrast to typefaces or fonts (which usually are obviously meaningful to designers only). I picked the background color, as foreground color already is used to tag links... Making colors configurable shouldn't be that big of a deal. But I'd only start this, once we have agreed upon the general method. Then, finding default configuration will be another task...but just a matter of taste and easily adjustable later.
I'm OK with coloring protected headers (this is my own opinion, this would have to be discussed by the whole team anyway), and for 3b, I would suggest to show the protected header (with emphasis) and use a tooltip to show a tip about what the emphasis is (a good place to show what's the non-protected header is). I think that such discussion, showing that more analysis has to be done, would better take place on the devel mailing-list.
I express my high appreciation that this moves forward now! I am also for 3b), but I also would vote that in cases "protected header" = "original header" somehow an information is revealed that a protected header is present. Colour coding also is not meaningful by default to all, and some displays or people are not colour-capable. I would add colour-coding as something configurable (maybe with a set default), but would call the header differently, e.g. prefix (or suffix) "(p) " or any other string to the protexted headers, e.g.: ``` (p) From: sender@example.com (p) Subject: Test email Subject: ... ``` Since text is universal, regardless of the capabilities of display or people's eyes. Make that configurable as well at best, so that people can choose if to prefix a string or not. And if it is put into a plugin (which I think would be a nice way to go) then the extra complexity is only there when the plugin is loaded.
Thanks, Felix, for your wishlist. I feel, that claws-mail is not written in a way that it can fulfill your wishes. It's Open Source Software, anyway, just go ahead and provide a patch that implements your desired features. Open Source doesn't mean clients desire and volunteers deliver: "free as in speech, not as in beer". I'll move on, for the time being stay with my legacy claws-mail client with my added features that does perfectly fulfill my requirements. At a certain point in time, I'll write my own mail reader, maybe, or just provide patches to my then-favourite client mail-SW.
Actually I was hoping for help by the community to augment my limited capabilities and knowledge of claws-mail, attempting to give back a valuable feature to a community that is built on sharing. What I found was a more than demanding community unable for years to decide whether or not to value collaboration, instead finally overloading my attempts with requirements. The point has come where I decided to not invest valuable time to follow up the intermediate result reached during wasted hours. Hence closing the issue as original reporter. Good luck in making claws-mail more successful than ever.
(In reply to claws-mail-devel from comment #57) Hold on, Holger. How did you come to this view? I found this turn around very surprising, since we just showed interest and offered to discuss this further with you on the devel mailing list. Suddenly, because we don't accept your patch as-is you throw in the towel and give up?
Frankly, after 30 month of not even discussion my proposal, this community is getting demanding and requesting me to add things I am even not aware on how to implement. I'm giving up any hope, that this feature will go upstream ever. This community will always find a reason why it's not good enough, and why I will have to spent more time to familiarize with the moving target. Not the time to head after the carrot, any more. Spent Effort has passed by the RoI line. I'm absolutely okay, if anybody else is going to augment my patch to fulfill the desired properties. I won't. The last thing you may request from me is a signed DCO, that would allow you to use and release my contribution under GPL.
Well well.. what is sure, is that your patch does not work here, it breaks things. In order to be integrated, the analysis would even also need to be performed, at least on the way things are tuned and displayed (I'm not discussing the base idea, which is right). IOW there's much work if you want your ideas into Claws Mail (but your own copy), we can afford a part of this work, or not, depends on our spare time and energy, I'm sorry.
(In reply to claws-mail-devel from comment #59) Claws Mail is GPL, therefore your patch is GPL too. Besides, most of your patch is re-worked CM code anyway.
@wwp - you are right. There is an awful lot of work to make my patch part of upstream CM. It works here, in first place. It has coding flaws, for sure, nonetheless sometimes a question of taste - with no preferred coding style documented. And, finally, you don't like the UI integration. Fair. There neither are UI style guidelines for CM. It's open source. Feel free to make a UI integration in the way you like, or discard the feature at all, your discretion as the project maintainers. I got my problem solved - I did offer a giveback. Accept it or not. Not my choice. EOD.
(In reply to claws-mail-devel from comment #56 and #59) Ahoj, > Thanks, [...], for your wishlist. I feel, that claws-mail is not written in a way that it can fulfill your wishes. > [...] > this community is getting demanding and requesting me to add things I am even not aware on how to implement. I ask for forgiveness if this sounds like I have made more and more "demands". This (you-called) "wishlist" of mine was just meant to be part of the discussion about how to display things, and think further from there. It would be completely enough for me if the protected headers support would be included in the minimal variant at first. After that is lifted, it is still possible to enhance it if wanted (or leave it if not wanted). > just go ahead and provide a patch that implements your desired features. I lack the coding and programming language skills to do that. Regards!
No worries, Felix. You just made clear to me, that UI integration is not at all my expertise. Nothing I can help the project with.
(In reply to claws-mail-devel from comment #64) > No worries, Felix. You just made clear to me, that UI integration is not at > all my expertise. Nothing I can help the project with. Maybe a patch that can be more easily included upstream could then be to get rid of all your specialised/coloured UI integration, and just provide the raw protected headers encoding in some function/plugin or so and a simple display without any styling, so you don't include any UI integration above the most basic one? Hm. I also don't know what is good now :-(.
(In reply to claws-mail-devel from comment #39) > Created attachment 2331 [details] I have tried the patch (with GTK2-branch, I had to change `static GdkRGBA` to `static GdkColor` to make it work) and it works well in message view. What is still missing for my personal ease of use is that the entries in the folder view get updated to the encrypted header, once the message has been decrypted. I have now integrated that patch in the Arch Linux AUR package `claws-mail-gtk2-git`. Thanks for the work, regards!
(In reply to linux.felixbecker2 from comment #66) > What is still missing for my personal ease of use is that the entries in the > folder view get updated to the encrypted header, once the message has been > decrypted. You mean 'message list' rather than 'folder view', I'm sure. However, the patch did this already. I think that this is not what is wanted, anyway. Certainly your corespondant dosn't want that because, when you reply, you reveal his/her encrypted Subject header. On reflection, having tried the patch, my view is that is works best without this patch: The encrypted headers are decrypted, along with the rest of the message body, and are displayed below the regular headers and above the message body. They are easy to read an there is no chance that you will unwittingly reveal an encrypted header in your encrypted replies. The patch gives some inconsistent behaviour between users: the updating of the message list, and the colours in the message view - perhaps more. In my (upstream) opinion, it is a mistake to add the patch (as-is) to the Arch package.
(In reply to Paul from comment #67) > (In reply to linux.felixbecker2 from comment #66) > > What is still missing for my personal ease of use is that the entries in the > > folder view get updated to the encrypted header, once the message has been > > decrypted. > > You mean 'message list' rather than 'folder view', I'm sure. You are right. > However, the patch did this already. I see, I have to leave the folder and return to the folder, then it is displayed. > Certainly your corespondant dosn't want that because, when you reply, you > reveal his/her encrypted Subject header. In a test I did, in a reply the unencrypted subject ("...") was set by default. What is the workflow that with the mentioned patch the encrypted headers are revealed to unencrypted? > In my > (upstream) opinion, it is a mistake to add the patch (as-is) to the Arch > package. Arch Linux AUR is Arch User repository, not official packages. One use case of the AUR is to add packages which are to be compiled differently than the official variant, so in this case I think it is OK. Adding a warning might be helpful. Regards!
Ahoj, (In reply to Paul from comment #67) > On reflection, having tried the patch, my view is that is works best without > this patch: The encrypted headers are decrypted, along with the rest of the > message body, and are displayed below the regular headers and above the > message body. They are easy to read an there is no chance that you will > unwittingly reveal an encrypted header in your encrypted replies. For me, protected headers (from Thunderbird users) are _not_ shown without this patch. > The patch gives some inconsistent behaviour between users: the updating of > the message list, and the colours in the message view - perhaps more. Despite that I don't know C/ C++ coding, I can maybe do stuff with just getting rid of features. Can you tell what actually is needed so that the patch can be integrated? Getting rid of colouring I might be able to do. Regards!
Right, Felix, TB and K9 protected headers are stored in the MIME preamble. Only protected headers stored in a separate mime part with Disposition: inline are displayed in the message section, as indicated by the Disposition...
Just a note for the ones following here: In another issue -- #4007 -- another patch to address this has been posted: https://www.thewildbeast.co.uk/claws-mail/bugzilla/show_bug.cgi?id=4007#c4
*** This bug has been marked as a duplicate of bug 4007 ***