I have never used this function and would like to save my current work emails in a separate database. I created the database, and think I am following the instructions from the manual, but I do not see any emails imported after about 40 mins. Since this is the first time I am importing emails, I expect it to be slow, but I wonder if I am doing something wrong. Here is my setup.
- Did you click the disclosure triangle to expand the Microsoft Outlook section?
- What operating system and version of DEVONthink are you running?
Yes, I did open the disclose triangle for both applications Apple Mail and Microsoft Outlook.
I have mac 15.5 and am on DT 4.0.2.
I did press Import many times too.
If you were pressing import on the top-level item shown in your screen capture, nothing will happen.
No, I clicked on specific mailboxes, e.g. Inbox and clicked Import; Sent and clicked Import.
How many emails are in your Inbox in Outlook?
I can see 550 emails in the inbox at the moment total (read and unread).
Here is the way the folders are showing up for Apple Mail (which I no longer use but have emails and want to import) and Microsoft Outlook (which I currently use and want to import).
I found one email imported from Apple Mail.
In DEVONthink, hold the Option key and select Help > Report Bug. Thanks.
When you click on an e-mail folder, do you wait for DEVONthink to list all the e-mails in the folder before pressing Import (once only)? I’m finding I need to do that.
I am getting a weird super-slow import of e-mails, but am troubleshooting that before I post more info about what’s happening 
Sean
1 Like
- What email client?
- What type of account, e.g., Exchange?
- How large a mailbox?
Apple Mail on Sequoia 15.5, local store of iCloud IMAP (full download), ~1,500 e-mails (~4MB) in the latest “problem” mailbox, which hadn’t completed after about 18 hours (about ⅚ of the way through by the time I decided to Force Quit).
I’ve figure it out since typing the above message (was working on figuring out a workaround when I saw your reply) – these are my archive e-mails from the late 90’s early 00’s, and DEVONthink is choking on those with the header
Content-Type: text/enriched;
That encoding type is supposed to do some basic formatting via plain text tags/source (some keywords are the same as HTML).
As soon as it hits one of those messages, DEVONthink goes into a tailspin, has a couple of hundred “hangs” according to Activity Monitor, and after about 20 minutes goes on to the next message.
The first time you click on one of these imported messages in DEVONthink, it shows the following in the body display area (after about 20 minutes and many hangs as shown in the Activity Monitor):
Double-clicking the text.enriched “file” just makes DEVONthink beep.
An imperfect way to find them in DEVONthink is to search for e-mails with 0 word count (imperfect as it finds truly empty e-mails). I can’t search for "text/enriched” or “” in the contents or for “text.enriched” attachments of the messages in Mail or DEVONthink as no results are returned.
Searching in the ~/Library/Mail/V10 folder returns no results.
I can do a successful Finder-level search for those strings if I drag the e-mails out of Mail – I can edit that header out of the raw .eml file, the message imports fine, but I wouldn’t want to drag out the 150k+ archive e-mails I have, or try and identify the messages first somehow.
While experimenting when drafting this message, I see I can select all the messages I want to export, choose “Save As…” and make sure “Raw Message Source” is the Format, and it will do a combined .eml file, which I could then search and replace to get rid of the header and the “ formatting terminator, then import into DEVONthink – I think this is what I’ll do for now.
Given how much of an edge case it is, it’s a bit much to ask for a full “text/enriched” interpreter in DEVONthink’s import routines, but maybe DEVONthink could be made to recognise that e-mail header on import and just handle it as plain text as the simplest case for decoding?
Anyway, it’s been an unexpected troubleshooting and documentation session, I’m going to try the above and see if I can feel smug about myself
Sean
1 Like
That took less than a minute to import the 1500 e-mails, and maybe a couple of minutes to get the file ready as I figured out the best steps – Yeeha! 
Hmm, so not quite all as ancient as I first suspected they would be - most recent ones with that encoding are from 2018. When DEVONthink has nothing else on its mind, I’ll try and import just those two and see if it chokes.
[Update 1] The two 2018 e-mails have this MIME part as just one of several, so it might only be the ones where text/enriched is the only Content-Type, or perhaps where it’s defined in the header, that DEVONthink is having issues. Will update this post as I test out how it handles these later ones. As a side note, TextEdit was surprisingly snappy when opening and searching a 1GB .mbox file on my 3.4GHz Quad-Core i5 2013 27” iMac with 32GB RAM running Sequoia under OpenCore Legacy Patcher. I’m sure an ARM Mac would be faster, but I’m slowing down myself, so maybe I wouldn’t notice 
[Update 2] So, yes, multi-part e-mails are mostly fine – the text/enriched section isn’t recognised, but at least it doesn’t choke for 20 minutes trying to import it, or for 20 minutes when trying to view it. I’ll probably still strip out this header/encoding type, that’s the next experiment.
[Update 3] There’s definitely a period of early use of that Content-Type that DEVONthink chokes on more than others, so I’m removing those MIME parts from the .mboxes because if I change the enriched to plain, it becomes the primary text/plain part and it looks worse then the real text/plain part.
[Update 4] Things seem to be going much more smoothly now - about half the e-mails have now been imported via mbox import. While the completist in me would like to get the “problem” ones in eventually, I’m pretty happy with the progress now (was starting to think it was infeasible to bring in my archive for whatever reason [suspected my older Mac to some degree]). DEVONthink is handling 1GB .mbox files with aplomb. Hope to be exploring more e-mail fun stuff tomorrow.
Goodness. The standard is from 1996. I never heard about it until now. It was apparently invented to allow some kind of formatting “even on teletype terminals” (when did those become extinct?). Nevertheless, it provided for colors and bold as well as italic text.
What does that mean? “I’m looking at multipart emails where one part is text/enriched”? Is that an attachment or a multipart/alternative of the e-mail? In the latter case, one should be able to remove it because there should be another alternative with the same content (but not formatting).
What does that mean? If you change the MIME type to “text/plain” you will of course get exactly that, ie a text with formatting instructions interspersed and no formatting.
If you can open the mbox in a text editor, as you said, it might be worthwhile looking closer at the text/enriched thingies. If they are attachments, you can’t do much. But if they are alternatives, there should be an … alternative, and you might be able to remove the text/enriched part.
As I state, it’s multipart. Yes, I can remove the text/enriched part from the 100 or so which are effectively blocking import into DEVONthink, but trawling through 160,000 e-mails for those ~100 that have text/enriched from across 20+ years, some with very complex parts where it’s hard to see all the separate parts, was a bit tedious.
Rather than trying to pick that one part out, I tried just changing the Content-Type to text/plain as a simple search and replace. However, the plain text representation of text/enriched is worse than the plain text representation of, well, text/plain when that was already also present, so I walked back from trying that. Think HTML source code-level readability as body text.
For now I’ve settled on removing the text/enriched part.
Sean
That doesn’t say anything. “multipart” is just saying that the e-mail has … multiple parts. Those parts can be attachments (think of an attached RTF file or PDF). Or they can be alternative parts, like an e-mail with the same content, once as a text/plain and once as text/html. And possibly a third time as a text/enriched.
As I said: if it’s an alternative part, you can remove it, because there should be the same content in this e-mail available in another format. If it is an attachment, you cannot simply remove it.
That’s a task for a script. It should read the mbox as a text, split it in parts at the -- borders, throw away all those parts with text/enriched and reassemble the mbox.
Which is ok for alternative multiparts.
I apologise for misspeaking, and perhaps confusing what you were talking about - as you were talking of “multipart alternatives” vs “attachments”, I was being lazy and referring to those mutipart alternatives as “multiparts”.
That said, I didn’t think there’d be confusion about what I was doing working through – i.e. trying to decide between editing or removing the multipart alternative. If that wasn’t clear, even with my misstatement, I’m sorry.
Not for this one off when I’m not scripting daily, so would spend more time researching how to do that script than I spent making those adjustments manually.
Yes, thank you, I got that from the above.
Sean