Version: 1.5.2 (using KDE 3.1.2) Installed from: SuSE Compiler: gcc version 3.3 20030226 (prerelease) (SuSE Linux) OS: Linux (i686) release 2.4.20-4GB One mailing list I belong to has a hard-and-fast rule against attachements. Unfortunately, their attachment scanner removes the "detached signature" but doesn't fix up the header to indicate "there is no signature" -- final result, some e-mail clients receive what appears to be "blank" messages [the client won't render the message unless the sig is there, but hitting "reply" often brings back the "missing" item...] Inline signing works for this particular list, but then I have to "remember" to switch from the default [openpgp plugin] before I hit send [especially annoying since I have the "cache passphrase timeout" or whatever it is set to the suggested/default 30 minutes -- no chance to go back and change the style] Is there a way to specify, per recipient, which particular "plugin" should be used? [normally I send messages either via "reply to list" or middle-clicking the folder, which is checked off as "folder holds a mailing list" -- the actual e-mail address is NOT in my address book proper. However, even if it were, I don't see any option for setting the crypto-style]
Subject: Re: New: how to specify crypto plug on a per-recipient or folder basis? It's currently not possible to specify this on per-recipient or per-folder basis. I'm not sure which of both methods would be better. If you deactivate the crypto plugin then KMail will use clearsigning by default. This way you can't accidentally sent PGP/MIME signed messages anymore. I'm using KMail this way and I always switch to the plugin if I want to use detached signatures.
Unforunately, deactivating the plugin somewhat defeats the purpose of having it in the first place, now doesn't it? In this case, it is one list out of a dozen or more that "freaks out" when an attached-signature is sent -- everywhere else seems to work with them just fine. [FYI, this is the "openoffice.org" user list] I can also forsee "down the road" that some additional (or just plain "different") crypto plugin will be developed, and e-mail conversations with one or more people might find that particular plugin to be "better than" others. I generally feel "it's the computer's job" to remember mundane facts like "fred prefers crypto method A, while bob prefers method B"...
Thank you for your feature request. Kmail1 is currently unmaintained so we are closing all wishes. Please feel free to reopen a feature request for Kmail2 if it has not already been implemented. Thank you for your understanding.
Instead of creating a new feature request, please confirm here if the wishlist is still valid for kmail2.