mirror of
https://github.com/spartanz51/tutabridge.git
synced 2026-06-24 10:54:32 +02:00
Anthony
299804459a
Wire the SMTP send path so that when Thunderbird hands the bridge a `multipart/mixed` message its non-text parts are forwarded as real Tuta attachments rather than dropped. Parser side (mail/parser.rs) * `ParsedMessage` grows an `attachments: Vec<Attachment>` field. * `extract_multipart_body_and_attachments` walks every part, treats anything carrying `Content-Disposition: attachment` or a `name=` parameter (and not a text/* type) as a file, decodes base64 / quoted-printable, picks up the filename from Content-Disposition first then Content-Type's `name=`. Send side (tuta.rs::send_mail_impl) * `build_added_attachments` generates a per-file session key, uses the existing `BlobFacade::encrypt_and_upload_multiple` to ship the encrypted blob bytes, then assembles a `DraftAttachment` aggregate with the random aggregate `_id`s the instance mapper requires. * After `DraftService` persists the draft, `build_attachment_key_data` reloads the resulting Mail, zips its `attachments[]` IdTuples with the session keys we kept locally, and produces `AttachmentKeyData[]` for both the top-level `SendDraftData` and its nested `parameters` aggregate (server reads from the latter). * Empty-attachments path is a no-op, matching the previous behaviour. Three new parser unit tests pin down the multipart-with-PDF happy path, the filename-fallback to Content-Type `name=`, and that `multipart/alternative` text parts are not misclassified as files.