refactor(mimefactory): separate rendering of message payload and sendable message by link2xt · Pull Request #8345 · chatmail/core

link2xt · 2026-06-17T22:50:52Z

This change separates rendering into two separate steps:

Rendering of the message payload without the From, Date and Autocrypt headers.
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.

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-Edit headers 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.

j-g00da · 2026-06-29T07:41:21Z

+                        if name.is_empty() {
+                            None
+                        } else {
+                            Some(name.to_string())
+                        },


nit: maybe this should be a default behavior for Address::new_address? I don't see a case when empty string would be actually desired.

Address::new_address is part of the mail-builder crate, for them it probably makes sense to construct such addresses. In any case, we cannot change it.

iequidoo · 2026-06-30T02:10:22Z

+    /// Consumes a `MimeFactory` and renders it into a message which is then stored in
+    /// `smtp`-table to be used by the SMTP loop
+    #[expect(clippy::arithmetic_side_effects)]
+    pub(crate) async fn pre_render(


Maybe render_queued() or smth like this? pre_render() is somewhat "vague", and i'm afraid it may be confused with pre-messages.

iequidoo · 2026-06-30T02:10:34Z

+    /// If true, Autocrypt header should be added before sending.
+    should_attach_pubkey: bool,

+    /// If true, OpenPGP compression may be used.


Then it should be may_compress

iequidoo · 2026-06-30T02:10:42Z

+    from_header.write_header(&mut inner_headers, 6)?;
+
+    if is_encrypted {
+        let unencrypted_from = Address::new_address(None::<&'static str>, from_addr.to_string());


Suggested change

let unencrypted_from = Address::new_address(None::<&'static str>, from_addr.to_string());

let unencrypted_from = Address::new_address(None::<&'static str>, from_addr.clone());

iequidoo · 2026-06-30T02:10:45Z

+
+    if should_attach_pubkey {
+        let aheader = Aheader {
+            addr: from_addr.clone(),


Suggested change

addr: from_addr.clone(),

addr: from_addr,

iequidoo · 2026-06-30T02:10:48Z

+            verified: false,
+        };
+        let autocrypt_header = mail_builder::headers::raw::Raw::new(aheader.to_string());
+        if is_encrypted {


Could be

let headers = match is_encrypted { true => &mut inner_headers, false => &mut outer_headers, }; ...

to deduplicate the code a bit

iequidoo · 2026-06-30T02:10:52Z

+            };
+
+            // Encrypt to self unconditionally,
+            // even for a single-device setup.


"... to not reveal which setup we have", IIRC.

…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.

iequidoo · 2026-07-01T18:41:08Z

-                } else {
-                    SeipdVersion::V1
-                };
+        let display_name = if is_securejoin_message && !is_encrypted {


Btw, this is apparently not the correct implementation of #7396 , see the protocol flow chart -- Alice should attach her profile (avatar, displayname, etc.) only at the final step, but not in the "vc-pubkey" message which is encrypted with AUTH. It seems this doesn't create any security issue, but it's just enough to send the profile at the final step. Also if we let Alice review "Securejoin requests" in the future before fully executing them, showing Bob's profile to Alice first (not otherwise) makes sense:

Since we want to give Alice the opportunity to review join requests (as a future improvement that doesn't require breaking the protocol), Alice can't send any private data in the second message. [...]

EDIT: For Bob it's even worse because he sends his displayname already in "vc-request-pubkey" apparently, so e.g. other broadcast subscribers can see it.

CC @Hocuri

This is not related to the refactoring, but i'd like this to be reviewed by others.

link2xt changed the title ~~fix: replace last_added_location_id with last_added_location_timestamp~~ MimeFactory refactoring and fixes Jun 18, 2026

link2xt force-pushed the link2xt/last_added_location_timestamp branch 4 times, most recently from 45102bc to 1956c42 Compare June 18, 2026 18:00

link2xt marked this pull request as ready for review June 19, 2026 01:33

link2xt marked this pull request as draft June 19, 2026 01:33

link2xt mentioned this pull request Jun 19, 2026

Sort messages sent while being offline by the time they are sent over SMTP #8112

Closed

link2xt force-pushed the link2xt/last_added_location_timestamp branch 3 times, most recently from 5f3c57c to f9c33de Compare June 20, 2026 01:02

link2xt mentioned this pull request Jun 20, 2026

Location streaming fixes #8351

Merged

link2xt force-pushed the link2xt/last_added_location_timestamp branch from f9c33de to e314fc0 Compare June 20, 2026 04:25

link2xt changed the base branch from main to link2xt/location-streaming-fixes June 20, 2026 04:26

link2xt force-pushed the link2xt/location-streaming-fixes branch from 3d4610c to b1b0e3f Compare June 20, 2026 04:29

link2xt force-pushed the link2xt/last_added_location_timestamp branch 2 times, most recently from ce43887 to 6abd90c Compare June 20, 2026 19:48

link2xt changed the title ~~MimeFactory refactoring and fixes~~ MimeFactory refactoring Jun 20, 2026

link2xt force-pushed the link2xt/last_added_location_timestamp branch from 6abd90c to e350dd6 Compare June 20, 2026 20:01

link2xt changed the base branch from link2xt/location-streaming-fixes to main June 20, 2026 20:02

link2xt force-pushed the link2xt/last_added_location_timestamp branch 3 times, most recently from a18ab11 to 2e20218 Compare June 20, 2026 20:38

link2xt mentioned this pull request Jun 20, 2026

refactor: move ensure_secret_key_exists into key.rs #8353

Merged

link2xt force-pushed the link2xt/last_added_location_timestamp branch 5 times, most recently from a39da96 to 1c19dd8 Compare June 22, 2026 10:07

link2xt changed the base branch from main to link2xt/location-streaming-fixes June 22, 2026 10:08

link2xt changed the title ~~MimeFactory refactoring~~ refactor(mimefactory): separate rendering of message payload and sendable message Jun 22, 2026

link2xt force-pushed the link2xt/last_added_location_timestamp branch from 1c19dd8 to efe7d0f Compare June 22, 2026 10:10

link2xt force-pushed the link2xt/location-streaming-fixes branch from 28522ff to b34bc43 Compare June 26, 2026 08:58

link2xt force-pushed the link2xt/last_added_location_timestamp branch 2 times, most recently from 606d7c7 to 23c8c8a Compare June 26, 2026 18:15

link2xt force-pushed the link2xt/location-streaming-fixes branch from b34bc43 to c85e622 Compare June 26, 2026 18:15

link2xt marked this pull request as ready for review June 26, 2026 18:24

link2xt requested review from Hocuri, iequidoo and j-g00da June 27, 2026 14:34

j-g00da reviewed Jun 29, 2026

View reviewed changes

iequidoo reviewed Jun 30, 2026

View reviewed changes

link2xt force-pushed the link2xt/last_added_location_timestamp branch from 23c8c8a to 9351ae3 Compare June 30, 2026 15:53

link2xt force-pushed the link2xt/location-streaming-fixes branch from c85e622 to 908b761 Compare June 30, 2026 15:53

Base automatically changed from link2xt/location-streaming-fixes to main July 1, 2026 12:02

link2xt added 2 commits July 1, 2026 12:09

fixup: simplify should_compress calculation

598ac45

link2xt force-pushed the link2xt/last_added_location_timestamp branch from 9351ae3 to 598ac45 Compare July 1, 2026 12:10

iequidoo reviewed Jul 1, 2026

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Uh oh!

refactor(mimefactory): separate rendering of message payload and sendable message#8345

refactor(mimefactory): separate rendering of message payload and sendable message#8345
link2xt wants to merge 2 commits into
mainfrom
link2xt/last_added_location_timestamp

link2xt commented Jun 17, 2026 •

edited

Loading

Uh oh!

j-g00da Jun 29, 2026

Uh oh!

link2xt Jun 30, 2026

Uh oh!

Uh oh!

iequidoo Jun 30, 2026

Uh oh!

Uh oh!

iequidoo Jun 30, 2026

Uh oh!

iequidoo Jun 30, 2026

Uh oh!

iequidoo Jun 30, 2026

Uh oh!

iequidoo Jun 30, 2026

Uh oh!

iequidoo Jun 30, 2026

Uh oh!

iequidoo Jul 1, 2026 •

edited

Loading

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

	let unencrypted_from = Address::new_address(None::<&'static str>, from_addr.to_string());
	let unencrypted_from = Address::new_address(None::<&'static str>, from_addr.clone());

Uh oh!

Uh oh!

Conversation

link2xt commented Jun 17, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

iequidoo Jul 1, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

link2xt commented Jun 17, 2026 •

edited

Loading

iequidoo Jul 1, 2026 •

edited

Loading