Dnia 27.10.2019 o godz. 17:52:03 Fourhundred Thecat pisze:
>
> I am using Postfix with Dovecot. I believe it is Dovecot who saves
> messages to maildir.
Not necessarily. I'm using Postfix with Dovecot too and I'm using Postfix's
default local(8) to store mail. I didn't enable Dovecot's LDA. That
Fourhundred Thecat:
> On 27/10/2019 17.10, Wietse Venema wrote:
> > Use the local(8) delivery agent. In your $HOME/.forward file, pipe
> > the mail into a program that encrypts it with your public key, then
> > writes the result to maildir.
>
> I am using Postfix with Dovecot. I believe it is
On 27/10/2019 18.20, Stephen Satchell wrote:
>> are you perhaps confusing decryption with verifying the senders signature ?
>
> No. Signature verification and decrypting are two separate operations.
> You will have to investigate how your mail client handles mail that has
> been encrypted with
On 10/27/19 7:38 AM, Fourhundred Thecat wrote:
>> Further, the client would need to support the decryption of
>> superencrypted mail,
> there will be no "superencrypted" emails. As I explained in the first
> sentence of my original description, I want to process only emails which
> are not already
On 27 Oct 2019, at 10:52, Fourhundred Thecat <400the...@gmx.ch> wrote:
> On 27/10/2019 17.10, Wietse Venema wrote:
>> Use the local(8) delivery agent. In your $HOME/.forward file, pipe
>> the mail into a program that encrypts it with your public key, then
>> writes the result to maildir.
>
> I am
On 27/10/2019 17.10, Wietse Venema wrote:
> Use the local(8) delivery agent. In your $HOME/.forward file, pipe
> the mail into a program that encrypts it with your public key, then
> writes the result to maildir.
I am using Postfix with Dovecot. I believe it is Dovecot who saves
messages to
Fourhundred Thecat:
[encryption at rest, but not whole-disk encryption]
> With my scheme, all emails would be stored encrypted on my server, and
> decryption key does not exist on the server (emails are decrypted on my
> local client)
>
> What would be the best way to implement this ?
Use the
On 27/10/2019 15.23, Stephen Satchell wrote:
> OP, let me ask this: your proposal appears to be to modify the delivery
> agent so that, instead of storing e-mail in cleartext, it insteads use
> the public part of a public/private keypair to encrypt the payload of
> incoming email.
I did more
On 10/27/19 6:48 AM, Fourhundred Thecat wrote:
> On 27/10/2019 13.29, Ansgar Wiechers wrote:
>> Several years ago I wrote something like that [1]. However, if your mail
>> server is untrusted I don't think there's a point in bothering.
>
> no server is 100% trusted. By this logic, should I
On 27/10/2019 13.29, Ansgar Wiechers wrote:
> Several years ago I wrote something like that [1]. However, if your mail
> server is untrusted I don't think there's a point in bothering.
no server is 100% trusted. By this logic, should I therefore give up?
> Even if
> you pass the mail through an
On 2019-10-27 Fourhundred Thecat wrote:
> when new email arrives, and it is not already encrypted, I would like to
> run it through a filter, which would encrypt the message with my public
> gpg key, as if the original sender has sent the email encrypted.
>
> Why do I want to do this ? Why not
Some while ago, I had a Perl script around Mail::GPG as mailbox_command,
or inside a procmailrc, I'm not sure. I had it trigger only for a
certain address extension, e.g. mailbox+...@domain.tld. It worked quite
alright.
> Can such filter work, without ever storing plaintext email on disk ?
>
>
> On Oct 27, 2019, at 12:20 PM, Matus UHLAR - fantomas
> wrote:
>
> Encrypting mail at postfix level could create false sense of security.
> How do you know that nobody can read it on the server bore it becomes
> encrypted?
>
> And what's the poing of encrypting mail to you, when it came
On 27/10/2019 10.25, Sam Tuke wrote:
As well as fetching the public key, it'd need access to a private key
too. I think the private key is considered the bigger problem, for
various reasons.
On 27.10.19 10:40, Fourhundred Thecat wrote:
The scheme that I am describing needs only public key on
On 27/10/2019 10.25, Sam Tuke wrote:
> As well as fetching the public key, it'd need access to a private key too. I
> think the private key is considered the bigger problem, for various reasons.
The scheme that I am describing needs only public key on the server.
Not sure why you would think
om: 400the...@gmx.ch
>Sent: October 26, 2019 10:46 PM
>To: postfix-users@postfix.org
>Subject: Re: postfix filter to encrypt incoming emails with public gpg
>key
>
>
>On 27/10/2019 06.26, lists wrote:
>> My bank insists I use their website for anything secure. I don't get
&
TLS makes no difference, but you might as run the server as close to normal as
possible.
Original Message
From: 400the...@gmx.ch
Sent: October 26, 2019 11:52 PM
To: postfix-users@postfix.org
Subject: Re: postfix filter to encrypt incoming emails with public gpg key
On 27/10
On 27/10/2019 07.27, lists wrote:
> Let me try again. So the email comes in. Some programs gets your public key
> and then encrypts the email on the server.
I imagine, in theory it should work like this:
New email comes in, and as it moves through the Postfix mail delivery
pipeline, at some
: 400the...@gmx.ch
Sent: October 26, 2019 10:46 PM
To: postfix-users@postfix.org
Subject: Re: postfix filter to encrypt incoming emails with public gpg key
On 27/10/2019 06.26, lists wrote:
> My bank insists I use their website for anything secure. I don't get anything
> in my email that
On 27/10/2019 06.26, lists wrote:
> My bank insists I use their website for anything secure. I don't get anything
> in my email that would be a security problem.
I used bank just as an example. Feel free to substitute another
scenario, if you find mine hard to imagine.
> Wouldn't a private key
My bank insists I use their website for anything secure. I don't get anything
in my email that would be a security problem.
That said, have you inquired if your bank will use pgp? I know that sounds like
crazy talk, but some banks have PGP. (OT but note Amazon can do PGP too.)
Wouldn't a
21 matches
Mail list logo
