Version: 0.34.0 Status: In-progress Format: Semantic Line Breaks
This document roughly describes how chat-mail apps use the standard e-mail system to implement typical messenger functions.
- Encryption
- Outgoing messages
- Incoming messages
- Forwarded messages
- Groups
- Set profile image
- Locations
- Miscellaneous
Messages SHOULD be encrypted by the
Autocrypt standard;
prefer-encrypt=mutual MAY be set by default.
Meta data (at least the subject and all chat-headers) SHOULD be encrypted by the Protected Headers standard.
Messengers MUST add a Chat-Version: 1.0 header to outgoing messages.
For filtering and smart appearance of the messages in normal MUAs,
the Subject header SHOULD be Message from <sender name>.
Replies to messages MAY follow the typical Re:-format.
The body MAY contain text which MUST have the content type text/plain
or multipart/alternative containing text/plain.
The text MAY be divided into a user-text-part and a footer-part using the
line -- (minus, minus, space, lineend).
The user-text-part MUST contain only user generated content. User generated content are eg. texts a user has actually typed or pasted or forwarded from another user. Full quotes, footers or sth. like that MUST NOT go to the user-text-part.
From: sender@domain
To: rcpt@domain
Chat-Version: 1.0
Content-Type: text/plain
Subject: Message from sender@domain
Hello world!
The Chat-Version header MAY be used
to detect if a messages comes from a compatible messenger.
The Subject header MUST NOT be used
to detect compatible messengers, groups or whatever.
Messenger SHOULD show the Subject
if the message comes from a normal MUA together with the email-body.
The email-body SHOULD be converted
to plain text, full-quotes and similar regions SHOULD be cut.
Attachments SHOULD be shown where possible. If an attachment cannot be shown, a non-distracting warning SHOULD be printed.
Forwarded messages are outgoing messages that contain a forwarded-header before the user generated content.
The forwarded header MUST contain two lines:
The first line contains the text
---------- Forwarded message ----------
(10 minus, space, text Forwarded message, space, 10 minus).
The second line starts with From: followed by the original sender
which SHOULD be anonymized or just a placeholder.
From: sender@domain
To: rcpt@domain
Chat-Version: 1.0
Content-Type: text/plain
Subject: Chat: Forwarded message
---------- Forwarded message ----------
From: Messenger
Hello world!
Incoming forwarded messages are detected by the header. The messenger SHOULD mark these messages in a way that it becomes obvious that the message is not created by the sender. Note that most messengers do not show the original sender of forwarded messages but MUAs typically expose the sender in the UI.
Groups are chats with usually more than one recipient, each defined by an email-address. The sender plus the recipients are the group members. All group members form the member list.
To allow different groups with the same members,
groups are identified by a group-id.
The group-id MUST be created only from the characters
0-9, A-Z, a-z _ and -,
MUST have a length of at least 11 characters
and no more than 32 characters.
Groups MUST have a group-name. The group-name is any non-zero-length UTF-8 string.
Groups MAY have a group-image.
All group members MUST be added to the From/To headers.
The group-id MUST be written to the Chat-Group-ID header.
The group-name MUST be written to Chat-Group-Name header
(the forced presence of this header makes it easier
to join a group chat on a second device any time).
The Subject header of outgoing group messages
SHOULD be set to the group-name.
To identify the group-id on replies from normal MUAs,
the group-id MUST also be added to the message-id of outgoing messages.
The message-id MUST have the format Gr.<group-id>.<unique data>.
From: member1@domain
To: member2@domain, member3@domain
Chat-Version: 1.0
Chat-Group-ID: 12345uvwxyZ
Chat-Group-Name: My Group
Message-ID: Gr.12345uvwxyZ.0001@domain
Subject: Chat: My Group: Hello group ...
Hello group - this group contains three members
Messengers adding the member list in the form Name <email-address>
MUST take care only to distribute the names authorized by the contacts themselves.
Otherwise, names as Daddy or Honey may be distributed
(this issue is also true for normal MUAs, however,
for more contact- and chat-centralized apps
such situations happen more frequently).
The messenger MUST search incoming messages for the group-id
in the following headers: Chat-Group-ID,
Message-ID, In-Reply-To and References (in this order).
If the messenger finds a valid and existent group-id,
the message SHOULD be assigned to the given group.
If the messenger finds a valid but not existent group-id,
the messenger MAY create a new group.
If no group-id is found,
the message MAY be assigned
to a normal single-user chat with the email-address given in From.
Messenger clients MUST init the member list
from the From/To headers on the first group message.
When a member is added later,
a Chat-Group-Member-Added action header must be sent
with the value set to the email-address of the added member.
When receiving a Chat-Group-Member-Added header, however,
all missing members the From/To headers has to be added.
This is to mitigate problems when receiving messages
in different orders, esp. on creating new groups.
To remove a member, a Chat-Group-Member-Removed header must be sent
with the value set to the email-address of the member to remove.
When receiving a Chat-Group-Member-Removed header,
only exactly the given member has to be removed from the member list.
Messenger clients MUST NOT construct the member list on other group messages (this is to avoid accidentally altered To-lists in normal MUAs; the user does not expect adding a user to a message will also add him to the group "forever").
The messenger SHOULD send an explicit mail for each added or removed member. The body of the message SHOULD contain a localized description about what happened and the message SHOULD appear as a message or action from the sender.
From: member1@domain
To: member2@domain, member3@domain, member4@domain
Chat-Version: 1.0
Chat-Group-ID: 12345uvwxyZ
Chat-Group-Name: My Group
Chat-Group-Member-Added: member4@domain
Message-ID: Gr.12345uvwxyZ.0002@domain
Subject: Chat: My Group: Hello, ...
Hello, I've added member4@domain to our group. Now we have 4 members.
To remove a member:
From: member1@domain
To: member2@domain, member3@domain
Chat-Version: 1.0
Chat-Group-ID: 12345uvwxyZ
Chat-Group-Name: My Group
Chat-Group-Member-Removed: member4@domain
Message-ID: Gr.12345uvwxyZ.0003@domain
Subject: Chat: My Group: Hello, ...
Hello, I've removed member4@domain from our group. Now we have 3 members.
To change the group-name,
the messenger MUST send the action header Chat-Group-Name-Changed
with the value set to the old group name to all group members.
The new group name goes to the header Chat-Group-Name.
The messenger SHOULD send an explicit mail for each name change. The body of the message SHOULD contain a localized description about what happened and the message SHOULD appear as a message or action from the sender.
From: member1@domain
To: member2@domain, member3@domain
Chat-Version: 1.0
Chat-Group-ID: 12345uvwxyZ
Chat-Group-Name: Our Group
Chat-Group-Name-Changed: My Group
Message-ID: Gr.12345uvwxyZ.0004@domain
Subject: Chat: Our Group: Hello, ...
Hello, I've changed the group name from "My Group" to "Our Group".
A group MAY have a group-image.
To change or set the group-image,
the messenger MUST attach an image file to a message
and MUST add the header Chat-Group-Avatar
with the value set to the image name.
To remove the group-image,
the messenger MUST add the header Chat-Group-Avatar: 0.
The messenger SHOULD send an explicit mail for each group image change. The body of the message SHOULD contain a localized description about what happened and the message SHOULD appear as a message or action from the sender.
From: member1@domain
To: member2@domain, member3@domain
Chat-Version: 1.0
Chat-Group-ID: 12345uvwxyZ
Chat-Group-Name: Our Group
Chat-Group-Avatar: image.jpg
Message-ID: Gr.12345uvwxyZ.0005@domain
Subject: Chat: Our Group: Hello, ...
Content-Type: multipart/mixed; boundary="==break=="
--==break==
Content-Type: text/plain
Hello, I've changed the group image.
--==break==
Content-Type: image/jpeg
Content-Disposition: attachment; filename="image.jpg"
/9j/4AAQSkZJRgABAQAAAQABAAD/2wBDAAYEBQYFBAYGBQYHBw ...
--==break==--
The image format SHOULD be image/jpeg or image/png.
To save data, it is RECOMMENDED
to add a Chat-Group-Avatar only on image changes.
A user MAY have a profile-image that MAY be distributed to their contacts.
To change or set the profile-image,
the messenger MUST add the header Chat-User-Avatar: base64:IMAGEDATA.
To bypass limits of headers, it is recommended not to use the outer header
and to limit the size to 20k.
To remove the profile-image,
the messenger MUST add the header Chat-User-Avatar: 0.
To distribute the image,
the messenger MAY send the profile image
together with the next mail to a given contact
(to do this only once,
the messenger has to keep a user_avatar_update_state somewhere).
Alternatively, the messenger MAY send an explicit mail
for each profile-image change to all contacts using a compatible messenger.
The messenger SHOULD NOT send an explicit mail to normal MUAs.
From: sender@domain
To: rcpt@domain
Chat-Version: 1.0
Subject: Chat: Hello, ...
Content-Type: multipart/mixed; boundary="==break=="
--==break==
Content-Type: text/plain
Chat-User-Avatar: base64:AKCgkJi3j4l5kjoldfUAKCgkJi3j4lldfHjgWICwgIEBQY ...
Hello, I've changed my profile image.
--==break==--
The image format SHOULD be image/jpeg or image/png.
Note that Chat-User-Avatar may appear together with all other headers,
eg. there may be a Chat-User-Avatar and a Chat-Group-Avatar header
in the same message.
To save data, it is RECOMMENDED to add a Chat-User-Avatar header
only on image changes.
In older specs, the profile-image was sent as an attachment
and Chat-User-Avatar: specified its name.
However, it turned out that these attachments are kind of unexpected to users,
therefore the profile-image go to the header now.
Locations can be attached to messages using standard kml-files with well-known names.
To send the location of the sender,
the app can attach a file with the name location.kml.
The file can contain one or more locations.
Apps that support location streaming will typically collect some location events
and send them together in one file.
As each location has an independent timestamp,
the apps can show the location as a track.
Note that the addr attribute inside the location.kml file
MUST match the users email-address.
Otherwise, the file is discarded silently;
this is to protect against getting wrong locations,
eg. forwarded from a normal MUA.
<?xml version="1.0" encoding="UTF-8"?>
<kml xmlns="http://www.opengis.net/kml/2.2">
<Document addr="ndh@deltachat.de">
<Placemark>
<Timestamp><when>2020-01-11T20:40:19Z</when></Timestamp>
<Point><coordinates accuracy="1.2">1.234,5.678</coordinates></Point>
</Placemark>
<Placemark>
<Timestamp><when>2020-01-11T20:40:25Z</when></Timestamp>
<Point><coordinates accuracy="5.4">7.654,3.21</coordinates></Point>
</Placemark>
</Document>
</kml>
To send an "Point of interest", a POI,
use a normal message and attach a file with the name message.kml.
In contrast to user locations, this file should contain only one location
and an address-attribute is not needed -
as the location belongs to the message content,
it is fine if the location is detected on forwarding etc.
<?xml version="1.0" encoding="UTF-8"?>
<kml xmlns="http://www.opengis.net/kml/2.2">
<Document>
<Placemark>
<Timestamp><when>2020-01-01T20:40:19Z</when></Timestamp>
<Point><coordinates accuracy="1.2">1.234,5.678</coordinates></Point>
</Placemark>
</Document>
</kml>
Stickers are send as normal images
with the additional header Chat-Content: sticker.
It is discouraged to send stickers together with user generated text, however, stickers can be used as a reply to a message and also the footer should be set as usual.
From: alice@example.org
To: bob@example.com
Chat-Version: 1.0
Chat-Content: sticker
Message-ID: Mr.12345uvwxyZ.0005@example.org
Subject: Message from Alice
Content-Type: multipart/mixed; boundary="==break=="
--==break==
Content-Type: text/plain
--
Hi there! I am using this new messenger!
--==break==
Content-Type: image/png
Content-Disposition: attachment; filename="sticker.png"
R0lGODlhpAGkAfe9AP+zd2eQkZhrI//z9v++PMb///+scrdDT3BtbtrZ2f/LQSsREcdIVf9 ...
--==break==--
Typical sticker formats are image/png, image/gif and image/webp.
Animated stickers are supported
by just using an image format that supports animation.
Messengers SHOULD add a Chat-Voice-message: 1 header
if an attached audio file is a voice message.
Messengers MAY add a Chat-Duration header
to specify the duration of attached audio or video files.
The value MUST be the duration in milliseconds.
This allows the receiver to show the time without knowing the file format.
In-Reply-To: Gr.12345uvwxyZ.0005@domain
Chat-Voice-Message: 1
Chat-Duration: 10000
Messengers MAY implement RFC 9078 reactions. Received reaction should be interpreted as overwriting all previous reactions received from the same contact. This semantics is compatible to XEP-0444. As an extension to RFC 9078, it is allowed to send empty reaction message, in which case all previously sent reactions are retracted.
Messengers SHOULD use the header In-Reply-To as usual.
Messengers MAY send and receive Message Disposition Notifications
(MDNs, RFC 8098,
RFC 3503)
using the Chat-Disposition-Notification-To header
instead of the Disposition-Notification-To
(which unfortunately forces many other MUAs
to send weird mails not following any standard).
If some action is required by a message header, the action should only be performed if the effective date is newer than the date the last action was performed.
We define the effective date of a message as the sending time of the message as indicated by its Date header, or the time of first receipt if that date is in the future or unavailable.
When receiving a message:
-
If the key exists, but belongs to another address
-
AND there is a
Chat-Versionheader -
AND the message is signed correctly
-
AND the From address is (also) in the encrypted (and therefore signed) headers
-
AND the message timestamp is newer than the contact's
lastseen(to prevent changing the address back when messages arrive out of order) (this condition is not that important since we will have eventual consistency even without it):Replace the contact in all groups, possibly deduplicate the members list, and add a system message to all of these chats.
Copyright 漏 2017-2021 Delta Chat contributors.