mirror of
https://github.com/spartanz51/tutabridge.git
synced 2026-06-24 10:54:32 +02:00
Anthony
93f0f82a30
Tuta's server never publishes `File._ownerEncSessionKey` on the recipient-side copy of a mail the user sent to themselves over SMTP. The TS client survives this because it caches each file's plaintext session key locally at send time and re-uses it for the inbox copy without going through `crypto_client.load::<TutanotaFile>()` — the Rust SDK has no such cache, so the bridge's previous retry-on-WS-event mechanism logged 'still not decryptable after retries' forever. Mirror the TS behaviour in `TutaSession`: * A small `HashMap<key, SelfSendCacheEntry>` keyed by `subject + from + first_recipient` (lower-cased + trimmed) — those three fields are preserved verbatim across the Sent and Inbox copies of a self-send, so the inbox-side lookup always finds the entry the send side just dropped in. * `cache_self_send_attachments` runs from `send_mail_impl` only when `is_self_recipient` is true (the recipient list contains the bridge's own address). Third-party recipients hit Tuta's normal pipeline, which populates File metadata before delivery, so caching there would just waste memory. * `try_self_send_cache` short-circuits `load_attachments_impl` for the inbox copy, returning synthetic `TutanotaFile` records (only the fields `mail_to_rfc2822` actually reads) alongside the plaintext bytes. The entry is consumed on hit — the .eml the prefetch writes next becomes the durable cache. * TTL = 1h, soft cap 50 entries (LRU eviction on insert). Seven unit tests pin the cache key normalisation and the self-send detection (positive when To/Cc match From, negative when either diverges, case-insensitive throughout).