refactor(mimefactory): separate rendering of message payload and sendable message#8345
Draft
link2xt wants to merge 1 commit into
Draft
Conversation
link2xt
changed the title
link2xt
force-pushed
the
link2xt/last_added_location_timestamp
branch
4 times, most recently
from
45102bc to
1956c42
Compare
link2xt
force-pushed
the
link2xt/last_added_location_timestamp
branch
3 times, most recently
from
5f3c57c to
f9c33de
Compare
link2xt
force-pushed
the
link2xt/last_added_location_timestamp
branch
from
f9c33de to
e314fc0
Compare
link2xt
force-pushed
the
link2xt/location-streaming-fixes
branch
from
3d4610c to
b1b0e3f
Compare
link2xt
force-pushed
the
link2xt/last_added_location_timestamp
branch
2 times, most recently
from
ce43887 to
6abd90c
Compare
link2xt
force-pushed
the
link2xt/last_added_location_timestamp
branch
from
6abd90c to
e350dd6
Compare
link2xt
force-pushed
the
link2xt/last_added_location_timestamp
branch
3 times, most recently
from
a18ab11 to
2e20218
Compare
link2xt
force-pushed
the
link2xt/last_added_location_timestamp
branch
5 times, most recently
from
a39da96 to
1c19dd8
Compare
link2xt
changed the title
…able message This change separates rendering into two separate steps: 1. Rendering of the message payload without the From, Date and Autocrypt headers. 2. Adding the From, Date and Autocrypt headers and possibly encrypting the message. The goal is to have serializable result of the first step that can be persisted in the database and sent later with any email address. This way it will be possible to send queued messages over any relay. This will make it possible not to remove all messages from the queue when the sending relay is changed. Currently changing `configured_addr` deletes everything from `smtp` table. This change is however only a refactoring and does not implement any features.
link2xt
force-pushed
the
link2xt/last_added_location_timestamp
branch
from
1c19dd8 to
efe7d0f
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This change separates rendering into two separate steps:
The goal is to have serializable result of the first step
that can be persisted in the database and sent later with any email address.
This way it will be possible to send queued messages over any relay.
This will make it possible not to remove all messages from the queue
when the sending relay is changed.
Currently changing
configured_addrdeletes everything fromsmtptable.This change is however only a refactoring and does not implement any features.
This is a refactoring PR in preparation for automatic relay failover.
As a side effect it also makes possible to change the Date of the message for #8112 if we decide on this approach (unlikely).
Serializable mail is currently called
mimefactory::QueuedMail. Everything except the public keys is trivially serializable, public keys should likely be serialized as recipient fingerprints rather than as OpenPGP certificates.I also noticed that we likely can remove the concept of "hidden headers" which are headers that are sent on the mulipart/mixed level of unencrypted messages. They are used to send
Chat-Editheaders and avatars in unencrypted messages. Sending avatars in unencrypted messages is not useful because they are not displayed anyway. And we can decide to make it impossible to edit and delete unencrypted messages. I have not changed anything in this PR, however, hidden headers work as before.Based on #8351