There should be a feature to add header, cc and bcc for the recipients who do not use delta chat (obviously, there is a fine line between a normal chat and an email☺)
The options for adding header, cc and bcc are missing.
Add member to a group option is just that, I guess (or delete member).
Hi@peta9
I belive the idea behind DeltaChat is a SMTP based messenger and not another mail client.
If you like to use a client with all features of a regular mail client, why not use a regular mail client (e.G. K9)?
A option to add BCC would mean in Deltachat to create a group with hidden members.
And that’s. not a good solution I suppose.
You know, a group is simply all recipients added to the “to:” field.
Ok, I got it. I, personally, do not like the skin of K9 mail. So, I was looking for an open source app (alternative to Gmail which I do not fully trust) that can fulfill my need. It would be great though, if those features were added, at least as extra options under the settings section, otherwise we have to keep 2 separate apps with incomplete but complementary features (and they will also undesirably consume more spaces in low end devices) 
Could you please explain, why it is not a good solution?
Adding all group members to the field To: will disclose relations between members in plain text on a server side, while leaving field To: as empty and using field Bcc: will eliminate such disclosure.
Besides of disclosure, many email servers have a limit for To: field on receiving side (how many emails might be included in field To: ), but if DC would use Bcc: each receiving server will see only originator’s email.
I don’t know much about technical details.
I should know who are the members in the group.
So I think If I use a regular mail client I can’t aswere to “all” if all group members hidden in BCC.
So group chat would not work if I understand it right.
(If looking for an K-9 email alternative, there is now also FairEmail on f-droid.)
I think the full standard email features may fit in with an eventual “Email” tab Add setting to show all people in DeltaChat (current contact request).
Only simple subject editing would make sense also within the chat interface. Some ideas: https://github.com/deltachat/deltachat-core/issues/128#issuecomment-423516046
There is even a bounty for editable subjects https://www.bountysource.com/issues/56768801-editable-subject-line.
Regular email IMHO shouldn’t make interference with deltachat. The whole point of DC is privacy.
What do you want to “answer” from regular email client to encrypted message if you can’t see content of this message?
No, if DC would make standard email message including email headers (that can contain To field) and encrypt it (wrap the whole message in encrypted container) then DC on receiving side will see all members of group from that internal field To: since it can decrypt it, but unencrypted email header(that visible in plain text for any1) should be send messages as Bcc:
This way man-in-a-middle won’t see all group members but DC will know group members on successful decryption of received message.
Check this Hide group emails from data mining thread with my proposal
The Idea behind DC is, I can reach everybody who has mailadress without he/she have to install a other client then a regular mailclient. This works also with web frontend.
If I use a mail client which supports autocrypt I can read encrypted messages.
Technical interested people also can use e.g the envelope addon for the web frontend.
So everybody who use PGP can read and answere this messages.
That’s what make the difference between DC and the other masses of secure messengers.
Of course that’s only my opinion.
I totally agree with webratte here. There is already XMPP/Jabber and Matrix for a decentralized chat protocol and IMHO the main advantage of DC over these is that the other side can simply use a normal mail client.
I think that using DC as a regular MUA client isn’t a good idea, there’re bunch of MUA for any platforms to read emails (with support of PGP or S/MIME encryption), the whole gist of DC is to exchange with encrypted, private messages, not a emails.
The logic behind my thoughts is simple: If message is encrypted using DC protocol, then it should be read by MUA that understand such protocol to be able to keep it private. As of now DC creating a huge problem on email accounts that used for normal emails and DC messages by spamming INBOX with useless for regular MUA encrypted messages and disclose information about peers in PLAIN text in field To:
While technically advanced people know about existence of PGP and how to encrypt/decrypt such messages, on other side IMO major population of users have no clue about this.
I would prefer to stay with old Unix wisdom, - “do one thing, but do it good”.
Mixing DC protocol with unaware about such protocol MUAs creating only issues and breaking the whole idea of private communication by disclosing recipients in field To: .
There is no special DC protocol.
DC uses the mail protocol SMTP and PGP encryption. 
So DC is actually also a mail client with a messenger UI.
That’s it.
As I said before. I can use DC and friends who not like to install another messenger can simple use there already installed mail client on phone, PC or also via web frontend.
If you like to use a closed system you should use something like XMPP.
So, basically DC is just another MUA with added autocrypt capability utilizing PGP encryption?
Then probably I missed something and overestimated it 
I thought that primary goal of DC is to establish truly decentralized, private messenger utilizing SMTP + IMAP IDLE push notifications…
Well, if it really just another MUA with added PGP encryption out of the box, then this explains mess in shared INBOX (when multiple MUAs accessing the same email account)
Thank you webratte to cool down me, but I still think DC is awesome project.
May be some days someone would get my idea to implement true private communication by wrapping the whole rfc822 message (including headers) in encrypted container and use internal/wrapped fields for everything and expose in plain text only those parts that needed to satisfy SMTP+IMAP without disclosing recipients emails on receiving servers.
Tnx again !
That’s one goal, I think, well combined with the “backwards” compatibility to communicate with billions of existing email users that have not yet installed an Email-chat client.
But another goal is, and hopefully continues to be in the current process of refactoring, that chat messages should not mess up the INBOX (are sorted well and moved into a special folder). But there are still some bugs to fix concerning this.
https://support.delta.chat/t/wiki-imap-strategy-to-chat-within-the-email-ecosystem/123/3
and
But there is no other Android client that support auto-crypt.
Btw, I am a happy user of both K-9 and DC. And would like it to be this way. Simply because DC is for quick just-in-time chats, and K-9 is for lengthy emails.
It’s great that I have all my chats and emails in single account, and can archive, search, and manage it. But it’s different functions, that should be done by separate apps.
P.s. I like dark mode of K-9. It’s not easy to switch to it, but after some time I find it more convenient than Gmail. Though I would support an initiative to move further it’s interface.