Subject of emails

Feature Proposal
1

Pretty please, give users a choice for how Subject is handled.

DC users don’t even see the Subject. It is seen by message recipients who are using another MUA.

There are so many posts about how Subject should be handled, both here on on Github. Maybe we can’t all agree on the best way to handle the Subject, and maybe that’s not even possible or necessary, if you give users a choice in how it is handled.

There are 3 types of Subject that I can think of:

  • A new email
  • A reply to an email that comes from Delta Chat
  • A reply to an email that comes from another MUA

If you want, you can also differentiate between emails to one address or to more than one address. This is the current behavior, though I think it unnecessary.

For each type of Subject, let the user decide what it looks like, using text and predefined fields. These fields could be

  • [First few words of the message]
  • [Group name]
  • [Existing subject] (works only if this is a reply)
  • [Prefix] – and let the user specify the prefix, such as “Chat:” If I want the subject to be [Prefix][Existing subject], then DC should check if [Existing subject] already has a prefix (whether it’s “Chat:”, “Re:”, or “Fwd:”) and remove it. This is the same behavior as most MUA’s have with the “Re:” prefix.

The current behavior is that new emails have the subject [Prefix “Chat:”][First few words of the message] if it’s to one email or [Prefix “Chat:”][Group name][First few words of the message] if it’s to more than one email. Some people (me!) might want to change this behavior.

Normies have no idea – and get weirded out by – Subject that starts with [Prefix “Chat:”][Group name]. I would much rather that my subject was just [First few words of the message] or [First few words of the message]([Group name]). That’s just me. Let users play around with how they create the Subject.

Expected behavior

User controls how Subject is generated in different types of emails.

Actual behavior

DC creates Subject in a pre-defined way, without user input.

7 Likes
2

Why was this flagged / hidden?

3

no idea, was done by the forum software for $reasons :slight_smile: also it’s marked as “unlisted” - is this intentional by you? or also a “special feature” of this forum?

EDIT: re-read your question and marked it as listed :slight_smile:

1 Like
5

Thanks!

6

I agree that changing the sending of Subjects with DC is worthwhile. Your suggestion requires, i guess, a lot of implementation and documentation work, though, and then after that maintenance and bug fixes. Do you have any simpler suggestion than “full customizability”?

1 Like
7

Yes. If I had to pick one, just [First few words of the message] is the best subject. It just tells people what’s in the message. It does not confuse people on other MUA’s with the weird “Chat:” prefix and the even weirder “Group name”.

8

If not seen already: https://github.com/deltachat/deltachat-core/issues/128#issuecomment-423133007

2 Likes
9

Then what the point to use encrypted communication if words from body leaking to unencrypted subject field ? Especially that DC is a chat program and usually body of messages in such apps contains a few words when people communicating, so basically your proposal defeat the gist of DC - encrypted communication.

6 Likes
10

Good point :+1:

3 Likes
11

What about a standard subject like:

“Chat: between chatstarter@anyhost.net and recipientOnChatStart@anyhost.net” ?

This way Chats can on MUA’s easy grouped.
The mailaddresses are anyway as plaintext in the header.

And for group chats maybe something like:

“Group chat: Group name”

4 Likes
12

Group name is also disclosing information.

Well, may be some1 wouldn’t like it, but IMO - it is either encrypted communication or just use plain emails. It isn’t possible to seat on two different chairs that stay far away from each other.

13

A group name can set carefully if it’s a sensible group (the most probably not).
So I think this would be “sufficient security”.

And there also could be a “paranoid” setting:

For every encrypted message set the subject to “encrypted message”.

1 Like
14

in fact, this is always and automatically done by Delta Chat.

whatever the subject is, it is not added to the unencrypted part of a message.

instead, the “real” subject is moved to the encrypted part and the “standard” subject is replaced by a placeholder [via spec/spec.md at master · deltachat/spec · GitHub]

4 Likes
15

When it comes to encryption/security there no other settings besides of “paranoid” :slight_smile:
It either encrypted/secure or it is not.

1 Like
16

Using autocrypt is always only “sufficient security”.
Theoretical a man in the middle could replace the public key in the unencrypted header.

So a self choosed subject (group name) ist not that security risk.

You could use the group name to confuse :wink:

Call the group “cooking group”

And inside the encrypted body you could organize a rebellion :yum:

17

nb: also with autocrypt, you can out-of-band verify keys, eg. using the “setup contact qr code scanning” in delta chat, even before sending the first message.

18

I didn’t get it. It is asymmetric cryptography, if associated with private key, public key changed then private key won’t decrypt such message, public key is part of the same puzzle that contains private and public keys. Loose one piece of puzzle and decryption will be broken.

I do have some thought about this issue: for those who turned on “preferred end-to-end encryption” in advance settings there shouldn’t be any leaking information and for those who don’t care about privacy they can choose to leak some limited info to unencrypted part of message.

19

@AlexJ

Here a theoretical and simplified scenario.

Alice send a mail to Bob.
In the (unencrypted) header is Alice’s public key.

The man in the middle catch this mail.
He replaced Alice’s key with his public key.
He send this mail to Bob.

Bob replay this mail and encrypt it with the key in the header by believing it’s Alice’s key.

The man in the middle catch this mail too.
Now he can read this mail.

Then he replace Bobs key, encrypt this mail with Alice’s public key.

And so on.

Of course, as @r10s already said, if you are carefully and check the fingerprints of the keys and the signatures it’s very secure (sufficient security) but not absolutely.

The same as by self choosed subject.
If you are carefully it’s sufficient secure.

20

i think there are very few things that are absolutely secure :slight_smile: