Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Define an event format for email. (SPEC-226) #99

Open
matrixbot opened this issue Sep 14, 2015 · 1 comment
Open

Define an event format for email. (SPEC-226) #99

matrixbot opened this issue Sep 14, 2015 · 1 comment
Labels
A-Client-Server Issues affecting the CS API enhancement A suggestion for a relatively simple improvement to the protocol

Comments

@matrixbot
Copy link
Member

Submitted by @​matthew:matrix.org
There are several email gateways hanging around now, and it's unclear how best to represent email. Is it a custom msgtype on an m.room.message? Does it track additional fields for the SMTP headers? Does it track all the headers? What about the envelope headers? How do we handle mails larger than 65K? Do we split attachments out into MXC URLs, or keep it all mime encoded? etc

(Imported from https://matrix.org/jira/browse/SPEC-226)

@matrixbot matrixbot changed the title Define an event format for email. Define an event format for email. (SPEC-226) Oct 31, 2016
@matrixbot matrixbot added the spec-bug Something which is in the spec, but is wrong label Nov 7, 2016
@turt2live
Copy link
Member

Related: matrix-org/matrix-spec-proposals#1225

@turt2live turt2live added enhancement A suggestion for a relatively simple improvement to the protocol and removed spec-bug Something which is in the spec, but is wrong labels Aug 7, 2018
@turt2live turt2live added the A-Client-Server Issues affecting the CS API label Feb 6, 2019
@richvdh richvdh transferred this issue from matrix-org/matrix-spec-proposals Mar 1, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-Client-Server Issues affecting the CS API enhancement A suggestion for a relatively simple improvement to the protocol
Projects
None yet
Development

No branches or pull requests

2 participants