On Sep 09, 2013 at 11:47 PM +1000, Erik Christiansen wrote:
To have an unencrypted subject line, it's necessary to enter it in mutt, prior to postponing. However, that's probably an asset if the subject ought also be obfuscated, E.g. "We go to war tomorrow" might be safer as "Immediate plans". If encryption were provided in mutt, the same could be done.
Well, encrypted messages that are actually sent don't have encrypted headers (or subjects), so while there might be security concerns with unencrypted subject lines, I don't see the need for them, nor does it appear to me that users of GPG or encrypted email have the capability for them.
I'm not sure what would happen if you added headers, subject or otherwise, prior to postponing but after writing the draft and encrypting in Vim (with Vim's builtin encryption). Vim's encryption turns the file into what looks like binary data, so tacking on a line or two at the top of that looks like a recipe for disaster.
Would the "postponed" mail folder ever be placed remotely, when security is the primary concern? (I don't use either of those, so my understanding of them is limited.)
If security was the primary concern, probably not. My larger point was that the encrypted file is no longer a valid file for the maildir structure. Note, I haven't tried doing the outlined process with mutt set to use the mbox file format; I don't know how mutt stores drafts with that setting.
Honestly though, I don't see your question as overly pertinent. If security is a primary concern, why are you sending (and storing) encrypted messages on a server to begin with? I don't think that's for me to answer. The way I look at it, a message in a drafts mailbox is a first class citizen under IMAP; it's just like any other message in terms of it's format for the most part. So if you are going to store an encrypted message in your inbox, or an encrypted draft in your postponed folder, shouldn't they share the same format and shouldn't the mail client interact with them in the same way?*
With GPG encryption at least, the expectation is that the body text is encrypted, either as ascii armor or as a MIME attachment. That would work perfectly fine in a drafts folder or as a sent/received message. Since mutt already has a mechanism and process for doing this with sent/received messages, it seems very convenient for the user to have the postponed draft system to work in the same way.
* Of course, with the obvious exception that a postponed message can have it's editing resumed at a later date.
