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

JMAP Email: rewrite JMAP Email to MIME conversion #4902

Closed
wants to merge 8 commits into from

Conversation

rsto
Copy link
Member

@rsto rsto commented Apr 29, 2024

This updates how MIME messages are created from JMAP Email objects for Email/set{create}. Changes include:

  • Inline plain text is rewritten before conversion regardless if its content is sourced from an EmailBodyValue or Blob. Non-plain text content now never is rewritten, even if it is defined with in a EmailBodyValue.
  • If the charset property for inline plain text declares the content to be ASCII or UTF-8, then the EmailBodyPart is rejected for invalid characters.
  • The content transfer encoding for "message" media types is chosen by the media subtype, e.g. handling "message/rfc822" and "message/global" differently.
  • Bare carriage returns in inline plain text now get expanded to CRLF, rather than omitted from the body part contents.
  • Transfer encoding names are written in lowercase, e.g. "8bit" rather than "8BIT", as recommended by

@rsto rsto marked this pull request as draft April 29, 2024 15:12
@rsto rsto force-pushed the jmap_emailpart_to_mime branch 4 times, most recently from 3aa7690 to b886660 Compare May 3, 2024 06:48
rsto added 8 commits May 16, 2024 14:00
Turns out that most uses of this function force a newline
before the parameter anyway, so don't require the caller
to provide the header prefix length.

Signed-off-by: Robert Stepanek <[email protected]>
It passed a non-ascii blob as text/plain content.
Email/set now sanitizes bare LF in inlined text bodies, rather than
keeping it as-is and using quoted-printable encoding.
A couple of tests created email attachments using binary
data without specifying the MIME type of the body part.
The new safeguards catch this as inappropriate values for
the default text/plain MIME type.
This updates how Email/set{create} creates MIME message from
JMAP Email objects.

- Inline plain text is rewritten before conversion regardless
  if its content is sourced from an EmailBodyValue or Blob.
  Non-plain text content now never is rewritten, even if it is
  defined with in a EmailBodyValue.
- If the charset property for inline plain text declares the
  content to be ASCII or UTF-8, then the EmailBodyPart is
  rejected for invalid characters.
- The content transfer encoding for "message" media types is
  chosen by the media subtype, e.g. "message/rfc822" and
  "message/global" are handled differently.
- Bare carriage returns in inline plain text now get expanded
  to CRLF, rather than omitted from the body part contents.
- Transfer encoding names are written in lowercase, e.g. "8bit"
  rather than "8BIT".
@rsto
Copy link
Member Author

rsto commented May 23, 2024

This is now part of #4926

@rsto rsto closed this May 23, 2024
@rsto rsto deleted the jmap_emailpart_to_mime branch May 23, 2024 10:49
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant