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 pus
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
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 your
++ 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 enc
Ó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 speake
!-- 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
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 hav
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 ha
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
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. The
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 do
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
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
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 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 c
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 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 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
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
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 the
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'da
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
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 se
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 careful
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 e
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
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 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
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 i
!-- On Sat 7.Sep'13 at 9:44:16 BST, Óscar Pereira (burn.till.s...@gmail.com),
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 encryp
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
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 w
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 t
-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 the whole disk with modern OS's, so
if the message is on your machine
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
> > hav
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.
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,
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
39 matches
Mail list logo
