Bug 431984

Hi there,

I am sorry if this is not the appropriate place for this feature request, but that's all I have found. (Please consider that English is not my mother tongue).

This is an idea that comes from years working in offices where everyone is overwhelmed by the high number of emails, including ones that are legitimate but of little interest to them specifically, just because they were "CC'ed". On the contrary, some might have overlooked the last email of a conversation they were not really interested in, while that last email contained a document they had to sign quickly. Etc.

Presently, one has to open an email and at least have a glance to it before they know how they should process / classify it, how much they should care or worry about it. Adding tags like [URGENT] or [PROJECT XYZ] in the email's object might be fine when there is only one recipient, but when someone is put in CC, just for their (possible) interest, they still see [URGENT] in the object and have no idea that they might as well read that email the next day.

So here is the idea from a GUI user point of view:

In front of the various recipient fields in the email composer, there is currently a drop-down list offering options "To", "CC", "BCC" and "Reply To". I think it would be great to be able to invent as many options as we want in that list. It would allow to specify how and why I intend to send my email to the recipient(s) in the corresponding field of the composer. For example, options could include "FYI", "Signature requested", "For review", "To be shared in your team", "Project XYZ".

Each recipient would then receive the email with the tag that was specifically intended to them by the sender. That tag(s) could be prepended to the email subject or appear at a dedicated spot in the email list item layout (KDE's tradition of high customisability could even enable users to choose). For example, for the same email (sent only once to multiple recipients, of course), one recipient would receive it tagged as "FYI" (and would then not worry to much about it); another recipient would receive it with the tag "Signature requested" and they would instantly know what is expected from them without even opening the email (some "email rule" might even be designed by the user to move such emails in a "To be Signed" folder), end so on.

More shortly: the idea is that it is the sender who suggests how the email should be handled/classified/considered. Plus, the suggestion is specific to each recipient. Although, obviously, the sender may enter several email addresses in a recipient field of the composer, thus assigning the corresponding tag equally to those several recipients. By the way, a recipient could also be in more than one recipient field (with some limitations regarding BCC, see below).

In the GUI, "To", "CC" and "BCC" would seem to be relegated to regular tags among the other ones, although they would probably be provided by default and "To" would be the default option of the drop-down lists.

From a UX perspective, tags could be managed by an option "Manage tags..." in the drop-down list in front of recipient fields. Clicking on it would lead to a very simple pop-up window allowing to enter a new tag, and delete or modify existing ones.

The special case of BCC: as said above, nothing prevents a given recipient from being entered in more than one recipient field. However, entering a recipient in a field tagged "BCC" and in another field would defeat the purpose of BCC. My opinion is just that, when the email composer validates the "form" it should refuse (and pop an error message) recipient addresses that are at the same time in BCC and in any other recipient field.

Here is now the idea of how it could be implemented (please consider I have only basic notions of computer programming and TCP/IP protocols, but the only things I know about email headers are from the Wikipedia page and a quick look at rfc5322):
It seems that there is no restrictions in the number and name of fields (other than character set). So each new recipient tag could be a new email header field with its own name. However in order to avoid mess with every email client developing their new fields, possibly identical for different purposes, I would opt for appending the tag label to "to-". For example, the tag appearing as "To be signed" in the composer would match the header field "to-To_be_signed".
Another option could be to use the already existing email header field "keywords", for example by adding the pairs "To_be_signed:alan@smith.com", "Urgent:alan@smith.com" (again, refraining to include BCC), but I don't see any advantage of this method over the first one.

So far, I haven't seen any reason to take special care of CC; it could be handled just as it has always been, just being now presented in the composer as a regular tag among many others.

Of course, at first, only Kmail/Kontact would be able to interpret those tags in received emails and make use of them, either by displaying their label in the email list, or prepended to the email subject, or by proposing to use them for email rules etc. But I think this would be so useful and long-awaited that it could increase the speed of Kmail/Kontact adoption. Then other email clients would kind of need to be able to interpret the "to-..." fields initiated by KMail in email headers if they want to keep up.

Last consideration I could think of: what if Alice has created a tag "To be signed" in her composer and Bob has created a tag "For signature"? They will write to me, and in my email list, their emails may appear with two different tags for the same purpose.

First: I think it's not a deal breaker; you might have two different wordings, you as a recipient are still able to know what to do and how much to care about those two emails. So the purpose of the feature and the energy, focus and time gain is still actual.

Second: in case of email rules relying on such tags, we can imagine rules based on regular expressions including "sign" (or just tag patterns with "?" and "*" wildcards, for users that are not in love with regular expressions).

Third: it might be the start for further development (not only by KDE, but in general) in two directions:
- standard tag sets (like emoticons/emoji/smileys) that could be provided by email clients or deployed by a company to all its employees' email client (in this case, I guess the tag management pop-up mentioned above should have an option to indicate a file, possibly on a network drive, listing the "corporate" tags);
- custom tag set included as a field in VCF cards; in this case, when you receive the a VCF card for a contact, you already know all the labels with which they may tag emails sent to you, and plan accordingly (rules, colours etc.).

The second option leaves unaddressed the issue of people updating their custom tags; it would be a hassle to send the update to all their contacts, then for them to update their rules etc.

A trade-off could be large standard tag sets shared across the world and email clients (like the large sets of emoticons/emojis/smileys in messenger apps) with the possibility to mark some of them as favorite, hence having those favorite ones on the top of the list when tagging a recipient field in the composer (or having only those favorite ones, the others being accessible through an additional click on, for example, "See all tags...").

Anyway, there will be some minor use glitches, like there are with any feature, but the job of telling the recipient in a blink how the email was intended specifically to them will be done.

I asked to maybe a hundred of people in my 13 years career in high-paced offices (I have worked in e-business for 3 years, then in field humanitarian action for 9 years), what they thought about this idea, and they all answered something like "it would be soooo greeeeaaaaaat, to have this!!!". I have never had the skills, time or will to push that further. But I have discovered the KDE paradigm like a year ago and I have been loving it since, starting with Kontact. And then I thought that this old idea I have kept in my head would fit well in it.

I am at the same time grateful and sorry if you have read until this point.
Cheers!