Closed Bug 437931 Opened 17 years ago Closed 8 years ago

STEEL API for accessing plain text message body

Categories

(Thunderbird :: General, enhancement)

enhancement
Not set
normal

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: patrick, Assigned: jminta)

Details

(Follow-up to bug 22687 comment 230). There is currently no easy way to access the unaltered plain text message body of emails (see e.g. bug 285715). However it would simplify things a lot for add-ons (like Enigmail) to have such an API. Possibly, the API could not only provide access to the plain text message body, but any kind of MIME (sub-)part.
Flags: wanted-thunderbird3?
Definitely wanted+, this might even want to block, because it feels like a pretty basic capability.
Flags: wanted-thunderbird3? → wanted-thunderbird3+
jminta pointed out to me that steelIMessage.getBody already provides the message body as a string for the common text-handling use cases. That's not going to work for Enigmail, I don't think, because it's likely to do conversion to Unicode, among other things. I think my suggestion that such an API should live in STEEL was a bit premature, because it's not clear exactly what other use cases there are here, nor what Enigmail would want an API to look like. Some questions: What API does Enigmail use today, and what's bad about it? Presumably, the S/MIME code has to deal with the same problem. What does it do? Does the newer better API want to be async? If not, why not?
(In reply to comment #2) > jminta pointed out to me that steelIMessage.getBody already provides the > message body as a string for the common text-handling use cases. That's not > going to work for Enigmail, I don't think, because it's likely to do conversion > to Unicode, among other things. Right, that might be a challenge. But having a unicode string plus knowing the original character codeset should be sufficient to convert the string back to the original charset. > I think my suggestion that such an API should live in STEEL was a bit > premature, because it's not clear exactly what other use cases there are here, > nor what Enigmail would want an API to look like. Some questions: > > What API does Enigmail use today, and what's bad about it? I have tried many variants already. Currently I'm mostly working with the textContent provided by messagepane/body. Depending on the result of the verification, I also directly load the message URL using nsIMsgMailNewsUrl using my own requestObserver. > Presumably, the S/MIME code has to deal with the same problem. What does it > do? Not really, we talk about inline-PGP only, where each MIME part is encrypted separately. S/MIME works like PGP/MIME, where the complete message (or a part of the MIME tree) is encrypted, i.e.the plain text body is not specially relevant. > Does the newer better API want to be async? If not, why not? I could live well with both options.
(In reply to comment #3) > (In reply to comment #2) > > jminta pointed out to me that steelIMessage.getBody already provides the > > message body as a string for the common text-handling use cases. That's not > > going to work for Enigmail, I don't think, because it's likely to do conversion > > to Unicode, among other things. > > Right, that might be a challenge. But having a unicode string plus knowing the > original character codeset should be sufficient to convert the string back to > the original charset. That seems unnecessarily inefficient (though it's good to know of the possible fallback). Let's see if we can't do better. > > I think my suggestion that such an API should live in STEEL was a bit > > premature, because it's not clear exactly what other use cases there are here, > > nor what Enigmail would want an API to look like. Some questions: > > > > What API does Enigmail use today, and what's bad about it? > > I have tried many variants already. Currently I'm mostly working with the > textContent provided by messagepane/body. Depending on the result of the > verification, I also directly load the message URL using nsIMsgMailNewsUrl > using my own requestObserver. Why two methods instead of one here? And what are the pain points that you're seeing?
(In reply to comment #4) > Why two methods instead of one here? And what are the pain points that you're > seeing? The problem is that messagepane/body/textContent does not guarantee to deliver the unmodified plain text body (e.g. extra spaces after smileys), so signature verification could fail even though the signature is valid. The main problem with re-loading the message body via a new requestObserver is that it's quite tricky. First you have to know which message part is the plain text body, which is quite difficult without having access to the mime-tree (if there is something then please let me know how to use it!). I just use Part1.1, but this could actually be wrong. Furthermore it sometimes seems to be slow. I think this is in case of IMAP or news accounts: if the message isn't stored locally, the message is re-fetched. And finally I think it's an unnecessary complicated solution for just having access to the email plaintext body.
I agree that there are two ways to look at the body: - One is what you want to *display* to the user (or for quoting). libmime outputs that generally in HTML (even for plaintext). That conversion is where the smilies come in, and only there. So, the result here is HTML, probably as string (sync) or stream (async). - The other is the on the *wire* format, i.e. RFC822. That can be text/plain, format-flowed, text/html, multiplat/related (embedded images), multiplat/mixed (attachments) or multipart/alternative (plaintext and HTML) or any combination of that, and any charset, quoted-printable etc.pp.. I'd output that either as satring (sync), stream for the whole message (async), or a tree of objects for each mime part, - that will get complicated in the API, but may well be the most convenient for those who need access to whole message, to attachments etc.. Re Enigmail, I don't really see a place where you'd get "plaintext" for a whole message. libmime does not really output plaintext, as far as I remember. Of course you can search for a text/plain MIME part, but it's a) not guaranteed to be there and b) not guaranteed to be your main body (e.g. when I attach a TXT file to an HTML message, which does happen in practice). If you only support plaintext, and you accept not being able to verify some valid messages, then just taking part 1.1 and checking for text/plain with a valid PGP sig is a cheap way. You could also look for any text/plain part any look for a PGP sig there. You'll also want to search for separated PGP sigs, i.e. the PGP sig MIME type and verify the next higher mime container with it, to support HTML and attachments.
For what it's worth, the STEEL getBody() method does wrap the requestObserver techinque described above, so that should be simpler with STEEL.
(In reply to comment #6) > - The other is the on the *wire* format, i.e. RFC822. That can be text/plain, > format-flowed, text/html, multiplat/related (embedded images), multiplat/mixed > (attachments) or multipart/alternative (plaintext and HTML) or any combination > of that, and any charset, quoted-printable etc.pp.. I'd output that either as > satring (sync), stream for the whole message (async), or a tree of objects for > each mime part, - that will get complicated in the API, but may well be the > most convenient for those who need access to whole message, to attachments > etc.. A kind of tree of objects for all mime parts would certainly be the easiest solution for extensions if we talk in the context of STEEL.
Is this still needed? Also, does it need to be in STEEL? What is the getBody() method mentioned here? I can't see it in STEEL. There is a similar method in nsMsgCompFields.
For reference, Firefox removed the STEEL equivalent (FUEL) in bug 1090880.
And steel is gone with Bug 1278067
Flags: needinfo?(patrick)
I think we can close this one.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → WONTFIX
Flags: needinfo?(patrick)
(In reply to Patrick Brunschwig from comment #12) > I think we can close this one. But was your use-case solved in another way? Did you find another function outside of STEEL to get your data?
Flags: needinfo?(patrick)
You can be quite sure that after 9 years, I did find a working solution ;-) Right now, I'm using the JSMime parser.
Flags: needinfo?(patrick)
You need to log in before you can comment on or make changes to this bug.