I'll reply to rest of email later, but I want to make two things clear. First, you accuse me of being intellectually dishonest, because I «attempt to ascribe» to you a scenario I thought up. I was (and am) not, but since that seems not to have been clear enough, I'll try to explain it more carefully. You wrote that
> 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. And you wrote this to justify why the drafts should be encrypted by the editor instead of mutt. So now suppose (*my* scenario, not yours) that mutt used an external program to view emails, and, we were discussing adding the feature of viewing encrypted emails to mutt. By a reasoning *similar* to yours, i.e. reasoning in a way coherent to yours, what would the conclusion be? Well, that because "mutt is not involved" in the process of viewing the email, decryption should happen within the external viewer, not mutt! See what I did here? My scenario, your reasoning. This is what I meant by "by your own logic". If you still can't understand it, and think it's me being intellectually dishonest, then I give up: I cannot put it into simpler terms. By the way, this is not a straw man, because I have not replaced the question, which is were should encryption or decryption happen (in mutt or an outside program). I took the reasoning you used in the case of drafts, and applied it to a hypothetical but possible scenario, to show you how it led to an undesirable conclusion. The only cause I can imagine for you to describe doing so as dishonest, is if you would apply a different reasoning for that different scenario. But then I'm left wandering why couldn't that different reasoning by applied to the drafts' case... Second, some parts of your email seem to suggest that you regard using the editor to encrypt the draft as the possible solution, rather than as the right one. I agree -- and as the original poster, thank you for it. But then you go on (or seem to go on) trying to justify using the editor as the proper solution, and proceed to do what seems to me as defending its merits (besides being the possible solution). Could you clarify which one are you trying to do? --Óscar On Sun, Sep 08, 2013 at 12:18:57AM +1000, Erik Christiansen wrote: > On 07.09.13 12:56, Óscar Pereira wrote: > > 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: > > > 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. > > Please _read_ the second last sentence! It makes your reply a straw man: > > > Do you realise that by your own logic, > > No, the following scenario of yours is entirely of your own creation, > and it is intellectually dishonest of you to attempt to ascribe it to > any another person, especially one whose logic has just ruled it out: > > > 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? > > It is fine for you fabricate such a proposal, but it is intellectually > dishonest to pretend that the fantasy is anything other than yours. > (What motive you have in substituting an editor for mutt's viewer, is > obscure, since you merely create problems which otherwise do not exist.) > > > > > > > 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. > > Relevance? The posed problem was unencrypted postponed drafts. A means > of encrypting them is what is needed. Are we both able to differentiate > a draft from a record of a sent email? The former currently needs > encryption, and a potential way to achieve that now has been described. > The latter is encrypted, so there is no problem to solve there. > > > As far as I know, *mutt* does that (*), not the editor. Am I wrong? > > No, you are agreeing with my statements about mutt handling email > sending. You could try reading the post to which you replied. > > > 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. > > Your assumptions about my reasoning have not been reliable hitherto. > I'd abandon that endeavor as unfruitful. > > > 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). > > If mutt ever acquires draft encryption, that integrated solution will be > easier to drive, and therefore better in the long term. A config option > will be needed, for enabling encryption. But a working solution is > significantly more useful today than a mutt feature which might or might > not ever eventuate. When, in the interim, an encryption-capable editor is > employed, mutt acts only as a transparent pipe between the editor and > the draft file, activated by P. > > > I'm not trying to start a flame here, but I am genuinely surprised > > by your reasoning. > > My reasoning is that a method which can provide encrypted drafts is > somewhat more useful than a method which does not exist. > > > > > 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. > > If mutt were modified to interpose encryption/decryption as an optional > filter between the editor and the filesystem, then that would be a very > fine solution. But it might never happen. In the interim, a solution > which can provide encrypted drafts now beats any imaginary solution. > > > > > > > > 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, > > Mutt can currently not do it. That means that it is for any available > tool to do, so that the posted problem can be solved now. Even a > frequently run cron job, which encrypted any unencrypted file in the > drafts directory, would do, until Santa delivers. > > > and that it might not even have the ability to do (for the sake of > > argument, say you > > No. Here you are again constructing a straw man. Fabricating a personal > fantasy purely of your own construction, admits an inability to deal > with the facts; to whit that I have proposed an editor as a prospective > solution which can solve the problem today. Why do you then persist with > the idiocy of proposing your own inferior substitute, just so that you > can criticise your own choice?: > > > 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. > > Err ... why did you post the problem if mutt is already capable of > encrypting drafts? > > > > > > > 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... > > Ahhh ..., you're not interested in a potential immediately deployable > method of draft encryption, then? > > Erik > > -- > The ultimate barrier is one's viewpoint. > - Terry Pratchett, "The Dark Side of the Sun" > -- Ó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
pgpDUlxMYFrYo.pgp
Description: PGP signature
