On Sat, Sep 07, 2013 at 07:51:41PM +1000, Erik Christiansen wrote: > On 07.09.13 09:44, Óscar Pereira wrote: > > On Sat, Sep 07, 2013 at 06:13:20PM +1000, Erik Christiansen wrote: > > > On 06.09.13 10:10, Derek Martin wrote: > > > > If it's sensitive enough to be encrypted outgoing, it's sensitive > > > > enough to be encrypted on disk... even if you haven't actually sent it > > > > yet. > > > > > > That's entirely convincing, but it doesn't follow that this has anything > > > to do with mutt, I figure. I use vim within mutt, and it is the editor > > > which needs to handle encrypted files, using whatever method(s) it > > > offers. Vim offers two levels of encryption - blowfish or zip. (OK, the > > > latter hardly qualifies, so there's only one method of any real > > > adequacy.) > > > > I don't think this is correct, because, by that logic, it would also > > be the editor's responsibility to deal with (i.e. decrypt) received > > encrypted emails... > > No, the "logic" which you have constructed there in unconvincing, due to > being erroneous. > > We use an editor to create the text for an email, so it needs to read > and write the encrypted postponed file - mutt is not involved, beyond > finding the file for the editor. On the other hand, we use mutt to read > received emails - no editor is involved normally. So your postulate is > false, due to there being no connection between the two processes.
Do you realise that by your own logic, if one was to use an external program (instead of mutt's default viewer) to view emails, that would mean that it would be **that program's** responsibility to decrypt the email before showing it to the user? Do you think this is a good way to handle encrypted emails? > > What you have seem to have missed is that the editor is not encrypting > the email for transmission. Mutt still does that. To this end, it is > necessary for the user to save the file unencrypted to the tmp file for > transmission, since encryption for transmission is mutt's job. (A finger > fumble here would send a doubly encrypted email, just as would happen if > the (encrypted) postponed file were attached by mutt without the > involvement of an editor.) What you seem to have missed is that when, for instance, you send an encrypted email, mutt saves a copy in the *local* sent folder, encrypted to your public key. As far as I know, *mutt* does that (*), not the editor. Am I wrong? If I'm not wrong, then what's so baffling about your reasoning is that you seem to be assuming that the (local) drafts folder is something that's totally unrelated to mutt, or to email, or whatever. Granted, before saving the encrypted-to-self copy mutt is involved in actually sending the email. But mutt is also involved when you save a draft, because you have tell **mutt** to store the draft! (by pressing P in the appropriate viewer). I'm not trying to start a flame here, but I am genuinely surprised by your reasoning. > > or are to be stored encrypted, then dealing with that is (or > > ought to be) mutt's job. > > No. Just because mutt encrypts for transmission does not obligate > it to encrypt other files which might or might not later be > transmitted. This is where you are conflating two separate tasks. > Another proposal on this thread was complete disk encryption. > Hopefully you do not see that as mutt's job? Nor is local > encryption of selected files. No I don't think it's mutt's job to do hard drive encryption. But I'm not conflating anything either, for mutt already has the ability to write encrypted emails to disk: see above. > > > I speak from a user's perspective, but doing as you suggest > > strikes me as a very bad design decision. But again, I speak as > > a user, so I might be wrong... > > Lack of understanding is resulting in a flawed perspective, I > submit. (And describing an offered potential real-world fix for a > posted problem as "very bad design" is hardly helpful. Perhaps you > can tell us what it contributes?) Let me clarify: it's bad design because 1) it assigns to the editor a task that it should not be for it to do, and that it might not even have the ability to do (for the sake of argument, say you used Notepad to write emails; then what?) and 2) it's bad design because it delegates on the editor a task that mutt is already capable of doing. > > What may be helpful to the OP is something which can work now, > albeit with the need to whack something in the editor to choose > whether we are postponing or posting. FYI I am the original poster... > > Erik --Óscar (*) - I assume mutt writes the encrypted email to disk by calling gpg with the appropriate options, but it's a task done by mutt nonetheless. > > -- On the basis of evidence we may be sure that we are wrong > but we can never be sure that we are right. - Richard > Feynman -- Óscar Pereira | https://erroneousthoughts.org Rules of Optimisation: Rule 1: Don't do it. Rule 2 (for experts only): Don't do it yet. -- M.A. Jackson
pgpfrRvpBEu63.pgp
Description: PGP signature
