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"
