Hey Heiko,
in the meantime, I made great progress with the "transport_filter" tool.
That was exactly what I was looking for.
In the current setup, I want to store a public and a private key for
each user, whereas the private key is encrypted by a password that is
only known by the user. For incoming messages, I use the public key to
encrypt them, for accessing those messages you need the private key,
respectively.
As mentioned in the documentation [1], you can use expansion variables
to pass to the "transport_filter". Is there an easy way to access the
user name or do you have to filter it out of the headers, e.g. by
accessing "Envelope-to:"? I thought about $recipients [2], but this is
not available for "transport_filter".
Best regards,
Gabriel
Quotes:
[1]
https://www.exim.org/exim-html-current/doc/html/spec_html/ch-generic_options_for_transports.html
[2]
https://www.exim.org/exim-html-current/doc/html/spec_html/ch-string_expansions.html
Am 2022-11-23 23:22, schrieb Heiko Schlittermann via Exim-users:
> Hi Gabriel,
>
> Dengler, Gabriel via Exim-users <exim-users@???> (Mi 23 Nov 2022
> 01:16:19 CET):
>> I want to store the incoming e-mails using the Maildir file format
>> encrypted
>> by using some symmetric encryption using the user's password (e.g.,
>> AES). So
>> in the end, Exim should write the encrypted files directly on the
>> disk.
>> Furthermore, it would be convenient if the actual password is solely
>> persistent saved as a hash (for checking at authentication), the real
>> password - and therefore the en-/decryption key - is only temporarily
>> available during the login session.
>
> Mybe I'm missing the point. The on-disk representation of the password
> is a hash. That can't be used for symmetric encryption/decryption.
>
> You want to "grab" the real password during user login, and save it
> somewhere for later use as encryption/decryption key?
>
> IMHO no source modification is necessary, $auth2, $auth3 (depending on
> the AUTH scheme you use (needs to be PLAIN or LOGIN) contain the
> password. You're free to save it whereever you want (using SQL, using
> embedded Perl code, using any external command, using readsocket, …)
>
> The encryption I'd do with a "transport_filter", which basically is
> can be an "aes-pipe" or similiar.
>
>> Therefore, I wanted to modify the Exim source code directly but was
>> confronted with a large amount of code, e.g., the differentiation
>> between
>> the different transport types or the many cases considered in the
>> appendfile
>> protocol. So I have some questions, where you might help me in the
>> "big
>> picture":
>
> As stated, all transports can use a "transport_filter", which should be
> able to processing your message on-the-fly, while writing it to the
> mailbox file.
>
>> * How to enforce that a user has to authenticate him-/herself with a
>> password?
>
> Use ACL to check if the user is authenticated. You should find it in
> the
> example config. Watch out for "authenticated = *".
>
>> * Where is a good point of "grabbing out" the password from the user
>> and how
>> to "carry" it to the point where the encryption happens?
>
> The authenticators (authenticators section of the config) have the
> password, and the server_condition does string expansion, so you can do
> whatever you need there.
>
> # example, *unchecked*, just served from memory, likely to be
> # wrong
>
> begin authenticators
>
> plain:
> driver = plain
> server_advertise_condition = ${if def:tls_in_cipher}
> server_condition = use $auth2 (user name) and $auth3
> (password) in a creative way
>
> Best regards from Dresden/Germany
> Viele Grüße aus Dresden
> Heiko Schlittermann
> --
> SCHLITTERMANN.de ---------------------------- internet & unix support
> -
> Heiko Schlittermann, Dipl.-Ing. (TU) - {fon,fax}: +49.351.802998{1,3}
> -
> gnupg encrypted messages are welcome --------------- key ID: F69376CE
> -
