Bug 1644027 Comment 19 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

The attached patch is a very preliminary concept using jsmime to get the a MessagePart of news. In the tree we have two implementations using the jsmime.

MimeParser: https://searchfox.org/comm-central/source/mailnews/mime/src/mimeParser.jsm
EnigmailMime: https://searchfox.org/comm-central/source/mail/extensions/openpgp/content/modules/mime.jsm

The first one has no emitter which actually returns the mime subparts, so I use the second one. There are a few differences to the output generated by MsgHdrToMimeMessage:
* size is not supported
* Headers differ slightly, MsgHdrToMimeMessage strips \t while Enigmail.getMimeTree does not. Also, getMimeTree includes sequences like `=?us-ascii?Q?1;DB5PR0201MB1463;23:Eg55ihvY4g752nWbP0chgz1qKWYuSIds73YLiq8?=`. 

Ideas on how to fix those?

We currently do not have to worry about encryption, as news are most probably not encrypted, but in the very end we should have a full-fledged jsmime based MimeParser, which also supports S/MIME and PGP. So all the different implementations we have should be merged. For now, I will probably copy the missing emitter pieces of EnigmailMime into MimeParser (including attachment support) and use that. 

Is there any benefit, to no longer get the raw mail first and parse the string, but use the async streamer support of MimeParser? Can that skip attachments (which is the only benefit I can see)?

What do you think?
The attached patch is a very preliminary concept using jsmime to get the a MessagePart of news. In the tree we have two implementations using jsmime.

MimeParser: https://searchfox.org/comm-central/source/mailnews/mime/src/mimeParser.jsm
EnigmailMime: https://searchfox.org/comm-central/source/mail/extensions/openpgp/content/modules/mime.jsm

The first one has no emitter which actually returns the mime subparts, so I use the second one. There are a few differences to the output generated by MsgHdrToMimeMessage:
* size is not supported
* Headers differ slightly, MsgHdrToMimeMessage strips \t while Enigmail.getMimeTree does not. Also, getMimeTree includes sequences like `=?us-ascii?Q?1;DB5PR0201MB1463;23:Eg55ihvY4g752nWbP0chgz1qKWYuSIds73YLiq8?=`. 

Ideas on how to fix those?

We currently do not have to worry about encryption, as news are most probably not encrypted, but in the very end we should have a full-fledged jsmime based MimeParser, which also supports S/MIME and PGP. So all the different implementations we have should be merged. For now, I will probably copy the missing emitter pieces of EnigmailMime into MimeParser (including attachment support) and use that. 

Is there any benefit, to no longer get the raw mail first and parse the string, but use the async streamer support of MimeParser? Can that skip attachments (which is the only benefit I can see)?

What do you think?
The attached patch is a very preliminary concept using jsmime to get a MessagePart object for news. In the tree we have two implementations using jsmime.

MimeParser: https://searchfox.org/comm-central/source/mailnews/mime/src/mimeParser.jsm
EnigmailMime: https://searchfox.org/comm-central/source/mail/extensions/openpgp/content/modules/mime.jsm

The first one has no emitter which actually returns the mime subparts, so I use the second one. There are a few differences to the output generated by MsgHdrToMimeMessage:
* size is not supported
* Headers differ slightly, MsgHdrToMimeMessage strips \t while Enigmail.getMimeTree does not. Also, getMimeTree includes sequences like `=?us-ascii?Q?1;DB5PR0201MB1463;23:Eg55ihvY4g752nWbP0chgz1qKWYuSIds73YLiq8?=`. 

Ideas on how to fix those?

We currently do not have to worry about encryption, as news are most probably not encrypted, but in the very end we should have a full-fledged jsmime based MimeParser, which also supports S/MIME and PGP. So all the different implementations we have should be merged. For now, I will probably copy the missing emitter pieces of EnigmailMime into MimeParser (including attachment support) and use that. 

Is there any benefit, to no longer get the raw mail first and parse the string, but use the async streamer support of MimeParser? Can that skip attachments (which is the only benefit I can see)?

What do you think?

Back to Bug 1644027 Comment 19