# Support normal mails in DCC for hybrid clients **URL:** \ **Category:** Feature Proposal\ **Created:** [March 22, 2019, 3:18pm UTC](https://support.delta.chat/t/support-normal-mails-in-dcc-for-hybrid-clients/326 "2019-03-22T15:18:02Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![VPracht](https://support.delta.chat/letter_avatar_proxy/v4/letter/v/6bbea6/32.png) [@VPracht](https://support.delta.chat/u/VPracht)\ **Post date:** [March 22, 2019, 3:18pm UTC](https://support.delta.chat/t/support-normal-mails-in-dcc-for-hybrid-clients/326/1 "2019-03-22T15:18:02Z")
As a pre-requisite for [Make DC a replacement for MUAs?](https://support.delta.chat/t/discussion-make-dc-a-replacement-for-muas/253) and hybrid chat/mail clients in general, the DeltaChat Core library should support sending and receiving arbitrary MIME mails. I see several ways to add the API to DCC, in order from least to most abstraction: 1. Send/receive raw bytes. Not stored in DCC database. Folders are simply strings representing the full path, i.e. starting with “INBOX/”. - pro: least effort for DCC - con: most effort for DCC clients, duplicate DCC functionality - con: need to expose more internals to access e2ee keys, etc. 2. New class allowing direct access to `libetpan`. Optionally stored in DCC database. Folders have their own class. - pro: reduced effort to implement now - con: more effort for clients on migration away from `libetpan` 3. New class with all necessary methods, abstracting `libetpan`. Optionally stored in DCC database. Folders have their own class. - pro: reduced efforts for clients - con: more effort to implement now - con: more effort for DCC to migrate away from `libetpan` 4. Extend the existing message class (`dc_msg_t`). Stored in DCC database. Folders can use either their own class or extend the existing chat class (`dc_chat_t`). - con: big change to existing APIs, code and DB - con: gets in the way / increases the learning curve for pure chat clients Just counting the pros and cons, options 2 seems the best so far. But before we start thinking about implementation detail, what are your thoughts and ideas about it? Maybe some completely different implementation ideas? ---
**Author:** ![hpk](https://support.delta.chat/user_avatar/support.delta.chat/hpk/32/9_2.png) [@hpk](https://support.delta.chat/u/hpk)\ **Post date:** [March 22, 2019, 8:31pm UTC](https://support.delta.chat/t/support-normal-mails-in-dcc-for-hybrid-clients/326/2 "2019-03-22T20:31:55Z")
Not sure this is a good forum for discussing what are rather implementation APIs and architecture questions. I’d rather suggest the mailing list. Let me still say a few things 🙂 I suggest to think more about the needed API and not too much about how it’s implemented. There is a lot of tentative/incremental flux that could happen in the next months, regarding moving code from C to Rust etc. And let’s maybe first talk about sending/receiving semi-arbitrary mime-mails, not about new/added IMAP handling. Which C-API would be needed and how would it work/be specified? How does Autocrypt-handling happen including encryption and decryption? If mime-mails are not tied to a chat at sending time, but to a caller-specified list of recipients, then how are they accessed on the receiving side? ---
**Author:** ![VPracht](https://support.delta.chat/letter_avatar_proxy/v4/letter/v/6bbea6/32.png) [@VPracht](https://support.delta.chat/u/VPracht)\ **Post date:** [March 28, 2019, 12:32pm UTC](https://support.delta.chat/t/support-normal-mails-in-dcc-for-hybrid-clients/326/3 "2019-03-28T12:32:47Z")
I created a thread on the mailing list ([archive link](https://lists.codespeak.net/hyperkitty/list/delta@codespeak.net/thread/VKTBGDJEMMYP6DG6VRBMO7Y6E4B6AX2V/)). ---
**Author:** ![r10s](https://support.delta.chat/user_avatar/support.delta.chat/r10s/32/1513_2.png) [@r10s](https://support.delta.chat/u/r10s)\ **Post date:** [February 18, 2026, 10:17am UTC](https://support.delta.chat/t/support-normal-mails-in-dcc-for-hybrid-clients/326/4 "2026-02-18T10:17:06Z")