Will there be a production version in the future?

[rsenger2]

I just managed to get this to work, after changing RRtype to 61 and removing base64 decoding of the keys.

My question, is this considered to be experimental only and forever, or will there be an update that can deal with multipart messages (especially, pgp signed messages delivered from an email client) and maybe dlv (I still need to use dlv.isc.org trust anchor...)?

I understand that real end-to-end encryption requires client side encryption, but I think this milter is interesting if the mail server is trusted (e.g. for companies).

[letoams]

On Tue, 10 Mar 2015, rsenger2 wrote:

I just managed to get this to work, after changing RRtype to 61 and removing base64 decoding of the keys.

My question, is this considered to be experimental only and forever, or will there be an update that can deal with multipart
messages (especially, pgp signed messages delivered from an email client) and maybe dlv (I still need to use dlv.isc.org trust
anchor...)?

I'm happy to work on bugs and maintain it - I do plan to pick this up
for a much needed update soon. I would really need some help if we
dive into the more complicated context parsing code. Someone with
more MIME experience for picking the right python modules and handling
code would be appreciated. It's not my area of expertise.

I understand that real end-to-end encryption requires client side encryption, but I think this milter is interesting if the mail
server is trusted (e.g. for companies).

It is still very useful. For instance when you have an mobile phone that
sends email via IMAP over TLS to your mailserver, which can then encrypt
it using OPENPGP.

[DanWin]

I'm working on an updated version of this and added multipart support to my fork: https://github.com/DanWin/openpgpkey-milter

[letoams]

Awesome! I’ll look at merge and release - sorry I haven’t given this project much attention lately ! Sent from mobile device

…

On Apr 13, 2019, at 11:46, Daniel Winzen ***@***.***> wrote: I'm working on an updated version of this and added multipart support to my fork: https://github.com/DanWin/openpgpkey-milter — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[ne20002]

I'll give it a few enhancement the next time.
Most email apps do have really good support of PGP encryption lately (Thunderbird, K9, ..) but I got a use case where the milter is really a benefit. :)
I run my own little instance of a Fediverse server along with my own mail server. A user asked if it would be possible to add pgp encryption for mail send by the system (mostly notification). I believe, using the milter will cover at least the 'simple' use cases much better.
This is on my list
[/] add config file
[/] allow skipping processing for domains
[/] allow skipping processing for configured recipients (not the whole domain)
[ ] add an additional query to keys.openpgp.org (as many users of public email providers don't have the option to add dns entries or email providers run a wkd)
[ ] cover the use case where there are recipients with and without pgp key by splitting the email and send one unencrypted and one encrypted

[letoams]

On Mon, 18 Sep 2023, ne20002 wrote: This is on my list [/] add config file [/] allow skipping processing for domains [ ] allow skipping processes for configured recipients (not the whole domain)

Yes, I have done some hardcoding on my running copy to do that :)

[ ] add an additional query to keys.openpgp.org (as many users of public email providers don't have the option to add dns entries or email providers run a wkd)

Note that if you want to add support for generic key servers where anyone can upload anything, that those keys have much less trust than keys from DNSSEC. At the very least, there should be a local keyring that is attempted before pulling from HKP keyservers.

[ ] cover the use case where there are recipients with and without pgp key by splitting the email and send one unencrypted and one encrypted

sure :)

[ne20002]

I got a few chnages running but I need further testing.
I changed order of resolving to 1st OPENPGPKEY DNS entry as this is the most secure option, if none found try to find key with WKD. And I added an optional query to keys.openpgp.org as this key server at least verifys the email addresses of uploaded keys. I call it with https (vks), not HKP. HKP servers seems to be filled with bogus keys.
A local keyring may reduce calls or resolving but may also hold outdated keys very fast so checking on every message seems to be the way at the moment.

I also realized that the use cases a (as no key for any recipient) and b (keys for all recipients) are easily to handle but the case c (keys for only some of the recipients) seems to not be solvable with a milter as it can't split messages into two. So 'letting go plaintext' is the only option here. But I will give some analyses on postfix content filters. maybe there is a solution.

At least, for my use case, where messages mostly have only single recipients, the milter works well.