> On Oct 22, 2019, at 9:08 PM, Viktor Dukhovni
> wrote:
>
> You see them not used. Kx=RSA. See ciphers(1):
Hi Viktor,
Thank you for sending this - for some reason, I had it in my mind that key
distribution was only via DH/DHE/ECDHE and I completely forgot about RSA (as
well as a couple
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
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.
There have been a few attempts addressing the needs of this complex use case.
AFAICS none have been successful, but I'm out of date.
See
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
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
Let me try again. So the email comes in. Some programs gets your public key and
then encrypts the email on the server. Then when you retrieve your email, it
sends it out in what it believes is plain text or for that matter can to TLS on
the file, but you get a GPG message that you then decrypt.
20 matches
Mail list logo
