thunderbird-android
thunderbird-android copied to clipboard
Add support for displaying message/rfc822 parts
When Emails are forwarded as attachment in outlook, the attached mail is shown by k9 as an attachment called noname.eml. K9 can not open this attachment, but hands it over to the standard mail client, which DOES show it. (Strangely, android mail can not open this attachment directly...)
Is it a bug or a missing feature that k9 can't open these attachments?
It's a missing feature.
Some spam filters attach potential spammy emails as .eml attachments. Unfortunately, I cannot read those in k-9 mail.
In case k9-mail gets support to open/view attached eml-files please also register it for this file-type so it will be offered upon touching on a eml-file in the file browser.
I often get emails with eml-attachments because people want me to assess possible spam emails. I only can do it by looking into the mail headers which requires the original mail to forwarded as an attachment (=eml). Currenty I have to save that eml-file from k9 and than to start the android file browser and than to display the eml-file in an text-editor.
(PS. Unluckily gmail-app DOES support both (open attached eml and open eml from file browser or k9) but has no option to display mail headers. Additionally it has a bug and won't display mails with eml-attachments at all. )
I wonder how best to do this. There are two ways I can think of, both with different problems:
-
insert the message into the database in some sort of temporary state or special folder. this immediately brings up the question which account and folder to associate it with, but all other loading logic can stay identical
-
change the loader to load a message from outside sources. this is relatively easy itself, just need to substitute the LocalMessageLoader in MessageLoaderHelper for another one with the appropriate logic. however it can't return a LocalMessage, so places where the actual LocalMessage methods (like makeMessageReference in onReply) are required that need different handling will naturally come up. It's just possible that way too many of these come up :)
Option 1 seems to be the easier path right? The message should be associated with the account the parent emails has been received with. In case the message has been opened from outside, e.g. file browser - the last used account / default account? For the folder I think something like a temporary folder (not synced via imap) will do.
PS. As for Gmail for Android, it will just open the eml in a limited viewer mode - no options to reply or forward - only viewing and printing. While I don't like this approach it could be considered as option 3 if the other ones bring to much problems.
Hello!
Are there plans to implement this? Spamassassin usually attaches originals as message/rfc822.
Ping?
Is there a known workaround for retrieving attachments from an attached email?
Hello, As a workaround you can install applications like "Letter Opener" or other .eml file viewers. I did not find yet decent open source .eml file viewer but I'll keep on searching. If would be better of course to have such feature right there in k-9 (and it would save me a tap ^^) but it makes .eml file viewing more comfortable than text file viewers. Kind regards,
Very often, I save those attachments to the mailbox, i.e. extract them from the enclosing email. This would require K9 to handle them internally.
might be unrelated to this issue, however I always see all attached .eml files with 0 B in size.
on Aug 4, 2015
It is clear that there is no will to implement this. Opening rfc822 part is for technical people only thus 0.00000% of users.
Opening .eml (which is the point there) files though is not only for technical people. Forwarding mails as enclosed documents is really frequent. Some mail system do that by default For example if you create rules in MS Exchange to forward urgent emails to your private mailbox the rule can only forward them as enclosed doc. A lot of people save important mail as local .eml files and send them later by email as enclosed files
Opening rfc822 part is for technical people only thus 0.00000% of users.
That seems vastly exaggerated, if not just wrong. See comments further above in this issue regarding forwarded email, email classified as spam, or email messages saved to files.
Rfc6109 is used by most (all?) italian businesses, and you get an eml when receiving mails from an unauthenticated domain. I can't really stress how dumb it is to say say this is just for nerds.
@fajabird I saw your comment from Feb 21, 2017
You say that gmail-app supports eml attachments. However, I noticed that this is (no longer?) the case now in 2024. For messages which have an eml attachment, neither the body (new text added while forwarding) is shown nor is it possible to open the attachment (forwarded message). I'm now wondering if there maybe is some special action or setting that is necessary to view such messages. Or whether this indeed got broken in the last 7 years.
Thanks for any info
Mhh fellas, this has been working for months at least for me.
Just to clarify: my question to fajabird was about gmail-app, not k9mail. I just posted here, because there seems to be no way of contacting him using other means (no e-mail, nor private message within github). Sorry for the confusion.
How is the current status? I've been noticing the missing .eml functionality for a while now and was hoping there was something newer about it tbh :/
This seems like the ideal ticket to put to a test on Mozilla connect. Would someone mind posting them over on Mozilla Connect? This is a great place for the community to discuss and help shape new ideas together, and is something we review regularly to determine the future roadmap. This quick guide has a few suggestions on crafting impactful suggestions. Focusing on the problem your idea solves and how it could help others can really make it stand out!
I can say as much that it isn't a priority for this year, but if someone is willing to put in extensive effort we could help out with some opinions on how to best integrate this.
As we're looking to move feature suggestions over to Mozilla Connect I’ll be closing this issue to keep our GitHub focused on active development, but I hope to see this idea over there.
(and please excuse the "not planned" resolution, there is no resolution for moved somewhere else, just fixed or not planned)
I could but i don't think it's really "just another idea" i mean a mail client that can't open mails...
Connect isn't simply for "just another idea". We don't have clear data on how common embedded message parts are due to lack of telemetry, and we don't have this feature right now. Connect right now is the only mechanism we have to figure out how popular this is.
Sorry but a mail client that does not open mails is really something bad. Whatever the mail client if you select several mails and click "forward" all the selected emails are enclosed as .eml files and forwarded, Thunderbird desktop included... having Thunderbird for Android unable to open mails forwarded by Thunderbird Desktop is so annoying for a day to day practise not only for private use but also for companies. Guys you'd really rethink this decision and consider this as an issue and a problem needing to be solved. It's not just a nice to have... it really impacts the usability of the product in a classical use case.
After trying to comment on the existing issue on Mozilla Connect and trying to log in, noticing that the GitHub-Signin option accesses my "private profile details" I lost the possibility to login through email, even after a full cookie and site data reset. So even if we disregard that the splitting of issues into two different pages (yes, there are a lot of accepted and current issues on GitHub), I can't even log in to Mozilla Connect. I would appreciate this issue being reopened, because it is really core functionality and could in my opinion even be tagged as a bug.
If you want to use connect to decide on the "priority" that's a thing.. But then it doesn't make sense to close the issue. Btw IIRC the problem isn't even with displaying emls per se, but only when there are multiple parts.
How and where we manage these features doesn't make a difference to the implementation. We won't have more time to work on this just because the issue is here as opposed to Connect. I feel it does make sense to keep the issue in one location. We regularly go through open issues, and if there are two locations then it just increases the mental load.
Really, I'm not trying to discuss this feature out of scope, closing it doesn't do anything like that. It is annoying that we're not able to display nested rfc822 parts, and I wish this were already a reality. Maybe it is actually trivial to implement, because, of course, we can already display rfc822.
I had exactly this discussion for I believe it was HTML Signatures, people were adamant that by me closing an issue it would never be on a roadmap and silently forgotten. Turns out it was one of the most wanted community features on Connect, and surprise, it is on this year's roadmap.
Please give me the benefit of the doubt on this :)
By now, there are 2 submissions for this feature in Mozilla Connect, so consider upvoting these as @kewisch suggested:
- https://connect.mozilla.org/t5/ideas/eml-support/idi-p/87395
- https://connect.mozilla.org/t5/ideas/tb-android-eml-file/idi-p/80757
@schmittlauch, I believe that I am unable to:
...as are others, per https://github.com/mozilla/fxa/issues/13947#issuecomment-2750127075.