External .eml files msg.Hdr.folder returns null

[critt74]

Hi,
I recently update to Thunderbird 115.5.1 (from 102.15.1) and I update Lookout to 6.1 version. Unfortunately the file winmail.dat is not unpacked and the attachments are not visible. Remove Winmail.dat is not set.

Thank you

[dugite-code]

Hi, please open the Error console (Ctrl+Shift+J) and look for any errors or warnings.

Also is the option Strict Content Type Matching enabled?

[critt74]

Yes there are errors

and yes, it is enabled
thank you
Cristina

[dugite-code]

I'm unable to re-produce this issue, it could be a corruption bug, if you're using IMAP could you try running a repair folder operation?

Right click the folder, Select properties and press the repair folder button

[critt74]

Hi,
my folder is not corrupt, I'll explain my problem better. I receive file .eml (externally Thunderbird) from certified e-mail address system (PEC in Italy) and I open this file with Thunderbird. Some time ago with thunderbird 102 and Lookout everything worked fine, I opened the eml file and if winmail.dat was there it was opened, but now it isn't. So today I try to import file .eml in a Thunderbird folder and....it works!!
While a single file .eml doesn't run ?

[dugite-code]

Ah I see the issue now. When you open an exported email saved to disk on your computer (in .eml format) in Thunderbird it fails to decode the winmail.dat file. I am able to reproduce now.

When you import that email back into the Thunderbird folder structure it will be able to decode.

Looks like L163 is using msgHdr.folder to fetch the msg URI. As the email isn't in a folder this will always return null

[cm-schl]

Hi,

I just played a bit with the extension to find a solution for this because I faced the same problem as @critt74 .
@dugite-code is right, the problem is that the uri is null when the mail is opened from a local filesystem or some other program that is not Thunderbird itself (for example an ERP that saved a mail as attachment where Thunderbird is used to open the .eml file).

As I didn't knew if uri is really needed in this situation I tried to set https://github.com/TB-throwback/LookOut-fix-version/blob/master/src/api/Attachment/implementation.js#L163 to uri: "", what seamed to work...
I'm not sure if we could always nail uri to an empty string. Maybe someone with more experience like @dugite-code or @jobisoft has a better insight 🙂.

[dugite-code]

The uri not being defined would potentially:

• Cause issues with other plugins
• Prevent sending the attachments in a decoded format

As we currently don't support that simply returning and empty string when msgHdr.folder.getUriForMsg(msgHdr) is null might adress the issue. Needs a bit of further investigation.