starred/cypht

Fork 0

mirror of https://github.com/cypht-org/cypht.git synced 2026-04-25 04:56:03 +03:00

[GH-ISSUE #12] Enhancement: support for more content types #7

New issue

Closed

opened 2026-02-25 21:33:53 +03:00 by kerem · 5 comments

kerem commented

2026-02-25 21:33:53 +03:00

Owner

Originally created by @dumblob on GitHub (Aug 3, 2015).
Original GitHub issue: https://github.com/cypht-org/cypht/issues/12

Originally assigned to: @jasonmunro on GitHub.

Nowadays it's quite common to send e.g. calendar invitations by email. Such email may have many Content-Type: headers. E.g. Google Calendar sends:

Content-Type: multipart/mixed
Content-Type: multipart/alternative
Content-Type: text/plain
Content-Type: text/html
Content-Type: text/calendar
Content-Type: application/ics

The ics part has Disposition: attachment, but all others are "inline". It would be very nice to have separate viewers (e.g. as Cypth modules) for different types - I can think of 3 basic ones (text/plain, text/html, text/calendar) and one more as my little personal wish (text/x-markdown and text/markdown). These viewer might be configurable (e.g. it's insecure to download all embedded/linked images when viewing the text/html content, so in configuration there would be a choice "show immediately" or "show a button load images" instead by default).

The goal would be to allow switching between them on demand. In a long run, some semantics can be used - e.g. the text/calendar viewer might render it using schema.org under the hood or provide direct links accept deny tentative in case you have a Gmail account.

Originally created by @dumblob on GitHub (Aug 3, 2015). Original GitHub issue: https://github.com/cypht-org/cypht/issues/12 Originally assigned to: @jasonmunro on GitHub. Nowadays it's quite common to send e.g. calendar invitations by email. Such email may have many `Content-Type:` headers. E.g. Google Calendar sends: Content-Type: multipart/mixed Content-Type: multipart/alternative Content-Type: text/plain Content-Type: text/html Content-Type: text/calendar Content-Type: application/ics The ics part has `Disposition: attachment`, but all others are "inline". It would be very nice to have separate viewers (e.g. as Cypth modules) for different types - I can think of 3 basic ones (text/plain, text/html, text/calendar) and one more as my little personal wish (text/x-markdown and text/markdown). These viewer might be configurable (e.g. it's insecure to download all embedded/linked images when viewing the text/html content, so in configuration there would be a choice "show immediately" or "show a button _load images_" instead by default). The goal would be to allow switching between them on demand. In a long run, some semantics can be used - e.g. the text/calendar viewer might render it using schema.org under the hood or provide direct links `accept` `deny` `tentative` in case you have a Gmail account.

kerem

2026-02-25 21:33:53 +03:00

closed this issue
added the
enhancement

imap

core
labels

kerem commented

2026-02-25 21:33:54 +03:00

Author

Owner

@dumblob commented on GitHub (Aug 7, 2015):

Now I noticed, that

Content-Type: message/rfc822

(sometimes incorrectly called eml) is being used (not sure how frequently) for forwarding messages etc., so it's another low-priority candidate for a separate viewer ;)

@dumblob commented on GitHub (Aug 7, 2015): Now I noticed, that ``` Content-Type: message/rfc822 ``` (sometimes incorrectly called _eml_) is being used (not sure how frequently) for forwarding messages etc., so it's another low-priority candidate for a separate viewer ;)

kerem commented

2026-02-25 21:33:54 +03:00

Author

Owner

@jasonmunro commented on GitHub (Aug 11, 2015):

Currently, formatting for different MIME types is contained in the IMAP module set, with a few bits in the "core" set (so other module sets, like POP3/feeds, can leverage them). I'm intrigued by the idea of abstracting these to individual module sets, but not sure yet if that is a good idea. Maybe MIME type formatting should be in the core set, or maybe a dedicated module set just for formatting different types. Great food for thought either way, so thanks yet again!

@jasonmunro commented on GitHub (Aug 11, 2015): Currently, formatting for different MIME types is contained in the IMAP module set, with a few bits in the "core" set (so other module sets, like POP3/feeds, can leverage them). I'm intrigued by the idea of abstracting these to individual module sets, but not sure yet if that is a good idea. Maybe MIME type formatting should be in the core set, or maybe a dedicated module set just for formatting different types. Great food for thought either way, so thanks yet again!

kerem commented

2026-02-25 21:33:54 +03:00

Author

Owner

@mat-m commented on GitHub (Mar 26, 2016):

I put a +1 on this.
Windows Live Mail sends Content-Type: multipart/alternative

with the text part beginning with

------=_NextPart_000_0080_01D1797B.99F0ABC0
Content-Type: text/plain;
    charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

The text part is not displayed in the inline message, and we don't have the download links for the many parts. Could you confirm it is related to this issue or if I should open a new one ?

@mat-m commented on GitHub (Mar 26, 2016): I put a +1 on this. Windows Live Mail sends `Content-Type: multipart/alternative` with the text part beginning with ``` ------=_NextPart_000_0080_01D1797B.99F0ABC0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable ``` The text part is not displayed in the inline message, and we don't have the download links for the many parts. Could you confirm it is related to this issue or if I should open a new one ?

kerem commented

2026-02-25 21:33:54 +03:00

Author

Owner

@jasonmunro commented on GitHub (Mar 26, 2016):

Multipart alternative messages are supported, it is a common message "container" type when sending a a message with plain text + html markup. If you have one that is not displaying properly, that is a different issue or potentially a bug. If you could open a new issue for that I would appreciate it!

@jasonmunro commented on GitHub (Mar 26, 2016): Multipart alternative messages are supported, it is a common message "container" type when sending a a message with plain text + html markup. If you have one that is not displaying properly, that is a different issue or potentially a bug. If you could open a new issue for that I would appreciate it!

kerem commented

2026-02-25 21:33:54 +03:00

Author

Owner

@jasonmunro commented on GitHub (Sep 24, 2018):

As a part of general issue cleanup, and an attempt to remove "generic" issues that are hard to actually address, I'm going to close this. Cypht supports a message parts section for IMAP messages that correctly shows all message part types and structure (IMHO, more so than any other webmail or desktop client I know of). What we lack is specific support for doing something with some message part types. For each of these we would like to support, I would like to create a specific issue so it can more directly be addressed.

Of the original types listed in the OP, the only types Cypht does not know how to do anything with (except provide a download) is the ics/calendar types. This is already covered in another issue (maybe 2), and s a part off some new work on CalDav/CardDav support that will hopefully be changing soon!

@jasonmunro commented on GitHub (Sep 24, 2018): As a part of general issue cleanup, and an attempt to remove "generic" issues that are hard to actually address, I'm going to close this. Cypht supports a message parts section for IMAP messages that correctly shows all message part types and structure (IMHO, more so than any other webmail or desktop client I know of). What we lack is _specific_ support for _doing_ something with some message part types. For each of these we would like to support, I would like to create a specific issue so it can more directly be addressed. Of the original types listed in the OP, the only types Cypht does not know how to do anything with (except provide a download) is the ics/calendar types. This is already covered in another issue (maybe 2), and s a part off some new work on CalDav/CardDav support that will hopefully be changing soon!

kerem referenced this issue

2026-02-25 21:35:35 +03:00

[GH-ISSUE #1411] 🐛 [Bug] Error when forwarding mail with attachment #650