| Commit message (Collapse) | Author | Age |
|---|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
There are many things going on here (perhaps a bit much for a single patch):
- When an attachment is of mime type "application/pgp-keys", a button is added to import the key to GPG
- When sending a mail and crypto is enabled (encryption, signing or both), the public key of the first private key found is sent as an un-encrypted attachment (T6994)
- The `mailcrypto.{h,cpp}` was, for the most part, rewritten
- Introduction of the expected monad, inspired by what was proposed for C++ [here](https://isocpp.org/files/papers/n4015.pdf), but not at all a strict implementation of this specification. We may want to add some more features of this standard later.
The rationale for some of the choices:
- I found mailcrypto a bit hard to edit to add new features, and a great part was commented code to prepare for the support the SMIME crypto format, which would (in my current knowledge) not be used for sending emails.
- One thing I found that may be missing in the code base was a standardized way of handling errors in C++ code. Since exceptions are disabled I think that the functional way is the way to go. After some research I found the Expected monad / tagged union / sum type, which seemed to suit the problem particularly well.
In the long run, I hope we would move the entire code base to use `Expected` to indicate if a function might fail.
Of course every choice made here is to be considered as a proposition for doing things / RFC, critics wholeheartedly accepted.
Reviewers: cmollekopf
Tags: #kube
Maniphest Tasks: T6994, T8147, T6995
Differential Revision: https://phabricator.kde.org/D11158
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Some notes:
- What we do is: if the mail is encrypted, decrypt it and copy its content into a new message (with plaintext, html and attachments, if any), and use this message as attachment for forwarding
- The `isEncrypted` function from KMime doesn't seem to detect every kind of encrypted mails. AFAIK this structure is not detected:
- `multipart/mixed`
- `text/plain`
- `application/pgp-encrypted` (attachement, named "ATT00001")
- `application/octet-stream` (attachment named "encrypted.asc")
Reviewers: cmollekopf
Tags: PHID-PROJ-6npnfcmppynqynn7slmv
Maniphest Tasks: T8112, T7024
Differential Revision: https://phabricator.kde.org/D10966
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Implement attachment-based forwarding.
Some notes:
- `loadAsDraft` was removed in favor of new enum `loadType` in QML, and callback based generic programming in C++
Reviewers: cmollekopf
Tags: #kube
Maniphest Tasks: T7024
Differential Revision: https://phabricator.kde.org/D10676
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
With i.e. "Mollekopf, Christian <mollekopf@example.org>", we'l end up
with an address "Mollekopf" and one "Christian <mollekopf@example.org>".
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
so we can start testing it.
|
| | |
|
| | |
|
| |
|
