Kevin J. McCarthy wrote:
Sorry to resurrect an old (and somewhat heated) thread, but I'd like
some feedback on the interface for a patch I'd like to push (attached,
or see ticket #3665). The patch was based off the one submitted by
Christian Brabandt, so thank you Christian!
I've just pushed
++ 07/01/15 14:57 -0800 - Kevin J. McCarthy:
I'm wondering if that is sufficient for people interested in the patch,
or whether a quadoption for postpone_encrypt would be more useful. For
a quadoption, I would keep the behaviour the same: the quadoption would
only be consulted if the message
Am 2015-01-07 23:57, schrieb Kevin J. McCarthy:
Óscar Pereira wrote:
The subject seems pretty self-explanatory. Use case, you're writing
an email, which is already marked as to be sent encrypted, but you
have to postpone it. In the meantime offlineimap runs and syncs you
mailboxes, and thus
Rejo Zenger wrote:
To me, that is of no particular use.
Against what version is the patch you have provided?
Thanks for the feedback.
The patch should apply against the tip of the default branch. It may
take a little bit of wiggling to get it to apply to something older
because of changes
Óscar Pereira wrote:
The subject seems pretty self-explanatory. Use case, you're writing
an email, which is already marked as to be sent encrypted, but you
have to postpone it. In the meantime offlineimap runs and syncs you
mailboxes, and thus your mail which is to be sent encrypted ends up
(For schedule reasons I was unable to reply earlier)
Erik,
It was never my intention to do anyone's thinking for them. At least
knowing you interpreted my words that way explains your reaction (I
would have reacted the same way). Perhaps that fault lies with me --
I am not a native English
!-- On Mon 9.Sep'13 at 20:33:43 BST, David Champion (d...@bikeshed.us), wrote:
I confess I haven't dug my way through the entire debate on this, but so
far I've seen argument along lines of: is it a necessary feature? if it
is necessary, is it necessary to be supported in mutt per se, or
Hello,
On Sun, Sep 08, 2013 at 08:14:47PM -0400, Tim Gray
wrote:
encrypting a mutt draft in Vim. You encrypt it,
then save the file, and once you are back in
mutt, postpone the message. It worked fine, as
long as you are ok with all the mail headers
being encrypted and thus inaccessible to
On Fri, Sep 06, 2013 at 11:05:16AM -0500, Dale Raby 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.
Well, its easy enough to encrypt the whole disk with modern OS's, so
if the message
On 07.09.13 18:00, Óscar Pereira wrote:
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,
On Sun, Sep 08, 2013 at 06:08:04PM +0100, Mick wrote:
Yep, I had more than once, on machine(s) with no vim. I've never managed to
learn how to use emacs, but as they say it's never tool late to learn to play
the piano! :p
It's more like an organ, and yes you do need the whole Cathedral.
On 08.09.13 20:14, Tim Gray wrote:
On Sep 09, 2013 at 02:31 AM +1000, Erik Christiansen wrote:
That would remove the editor choice restriction, and so would be more
universal once it exits. Added to that, draft encryption integrated
into mutt uses less keystrokes and requires less user
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
On Fri, Sep 06, 2013 at 11:05:16AM -0500, Dale Raby 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.
Well, its easy enough to encrypt the whole disk with modern OS's, so
if the message
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
On Sun, Sep 08, 2013 at 01:47:39AM +1000, Erik Christiansen wrote:
Yes, that is what I (perhaps too briefly) alluded to in the paragraph
quoted above. Writing to that tmp file is entirely under editor control,
with mutt providing only a temporary filename and a transparent pipe.
And in so
On Mon, Sep 09, 2013 at 10:20:33AM -0400, Tim Gray wrote:
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.
Right. There
On Mon, Sep 09, 2013 at 10:39:09PM +1000, Erik Christiansen wrote:
If we can each just argue our own case, then the list can be spared a
lot of noise.
That's a grand idea (seriously), but this is isn't debate club. Most
people have litte or no training in formal logic, and while if you
have
I confess I haven't dug my way through the entire debate on this, but so
far I've seen argument along lines of: is it a necessary feature? if it
is necessary, is it necessary to be supported in mutt per se, or can it
be done externally?
I haven't seen any discussion of what use models it would
On Mo, 09 Sep 2013, David Champion wrote:
I confess I haven't dug my way through the entire debate on this, but so
far I've seen argument along lines of: is it a necessary feature? if it
is necessary, is it necessary to be supported in mutt per se, or can it
be done externally?
I haven't
Hi Erik!
On So, 08 Sep 2013, Erik Christiansen wrote:
On 07.09.13 14:40, Christian Brabandt wrote:
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
On 08.09.13 14:59, Christian Brabandt wrote:
Vim certainly could and Emacs probably can encrypt. But what about Nano,
pico, mcedit, gedit, kate? Therefore, I think, it is still mutt's
responsibility to encrypt the file.
G'day Christian,
That would remove the editor choice restriction, and
On Sunday 08 Sep 2013 17:31:43 Erik Christiansen wrote:
On 08.09.13 14:59, Christian Brabandt wrote:
Vim certainly could and Emacs probably can encrypt. But what about Nano,
pico, mcedit, gedit, kate? Therefore, I think, it is still mutt's
responsibility to encrypt the file.
G'day
On Sep 09, 2013 at 02:31 AM +1000, Erik Christiansen wrote:
That would remove the editor choice restriction, and so would be more
universal once it exits. Added to that, draft encryption integrated
into mutt uses less keystrokes and requires less user concentration than
encryption provided by
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
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
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
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
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
On 07.09.13 14:40, Christian Brabandt wrote:
Hi Erik!
G'day Christian. A thoughtful response is most welcome.
On Sa, 07 Sep 2013, Erik Christiansen wrote:
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,
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
On Thu, Sep 05, 2013 at 06:45:46PM +1200, Chris Bannister wrote:
On Wed, Sep 04, 2013 at 05:30:16PM +0100, Óscar Pereira wrote:
Dear all,
The subject seems pretty self-explanatory. Use case, you're writing
an email, which is already marked as to be sent encrypted, but you
have to
On Fri, Sep 06, 2013 at 11:05:16AM -0500, Dale Raby wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
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.
Well, its easy enough to encrypt
On Wed, Sep 04, 2013 at 05:30:16PM +0100, Óscar Pereira wrote:
Dear all,
The subject seems pretty self-explanatory. Use case, you're writing
an email, which is already marked as to be sent encrypted, but you
have to postpone it. In the meantime offlineimap runs and syncs you
mailboxes, and
On Thu, Sep 05, 2013 at 06:45:46PM +1200, Chris Bannister wrote:
On Wed, Sep 04, 2013 at 05:30:16PM +0100, Óscar Pereira wrote:
The subject seems pretty self-explanatory. Use case, you're writing an
email, which is already marked as to be sent encrypted, but you have to
postpone it. In the
Dear all,
The subject seems pretty self-explanatory. Use case, you're writing
an email, which is already marked as to be sent encrypted, but you
have to postpone it. In the meantime offlineimap runs and syncs you
mailboxes, and thus your mail which is to be sent encrypted ends up
in (say) Gmail's
36 matches
Mail list logo
