Hi Erik!
On Sa, 07 Sep 2013, Erik Christiansen wrote:
>
> 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.
>
> 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.)
>
> It might be convenient to add a pair of mappings to .vimrc, to more
> fluently deal with postponing and posting, respectively.
You are being serious here? mutt spawns the editor with some template
file that is lying around in some tmp/ folder. After you have finished
writing the file and quit the editor, mutt reads that temporary file
(probably also unlinks it already) and asks you what to do with it (e.g.
postpone, send, etc.) At that dialog, you can also chose whether to
encrypt the mail or not (sign/encrypt+sign,etc). And if you decide to
encrypt the mail, it is mutt's responsibility to do so (which it should
possibly also do, when the mail will be postponed). I don't see, how
your editor comes to mind here, especially, since your editor doesn't
even know where to save postponed mails.
> > Mutt's job is to handle emails,
Exactly
> 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.
Yes it does, since mutt manages a mail store. Just because the mail ends
up saved locally, doesn't mean it always will and only mutt knows,
whether the mail will be send or postponed or moved to trash or similar.
> > 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.
It seems to me, you lack some understanding here ;)
regards,
Christian
--
A novice asked the master: "I perceive that one computer company is
much larger than all others. It towers above its competition like a giant
among dwarfs. Any one of its divisions could comprise an entire business.
Why is this so?"
The master replied, "Why do you ask such foolish questions? That
company is large because it is so large. If it only made hardware, nobody
would buy it. If it only maintained systems, people would treat it like a
servant. But because it combines all of these things, people think it one
of the gods! By not seeking to strive, it conquers without effort."
-- Geoffrey James, "The Tao of Programming"
