By default, Olminator is configured to handle your input .olm file without any need for fiddling around with settings. It will simply convert all input contained in the .olm file, honor file size limits and other constraints that some vastly popular email, calendar and contacts applications on your Mac may be thankful for.
In the unlikely event that those default settings won't work for you, you can adapt them to your needs to some extent:
As of v3.0, Olminator comes equipped with a Profile feature that allows you to have several sets of settings in parallel. This allows you to quickly switch between distinct settings used for converting different .olm archives. Configuration settings that are Profile dependent are all settings in the Settings section, except those in the General Debug sections (see below). If you hover over the Profile section, those excluded sections will be shown in faded-out fashion to indicate they are not relevant depending on the specific Profile, but are used with the same setting across all individual Profiles equally.
The following features are available for working with a Profile:
Hint: A .mbox container file for emails is nothing else than the combination of many .eml formatted emails into a single file, or in other words: A .eml file is an .mbox file with just a single email contained in it.
Caveat: Some applications, like Apple Mail, can't import .mbox files exceeding a certain size limit. For Apple Mail, this limit appears to be around 2GB.
This is an Apple Mail-only feature.
Hint: Apple Mail does not import duplicates in a folder, which will result in numbers of mails in an export folder potentially differing from the number of emails in the respective import folder, which might cause confusion. Therefore, Olminator can hint you at such duplicates (= just log a warning), keep the duplicate but make it unique by adapting its message ID to make it unique and hence keep Apple Mail from dropping it (= keep the duplicate but make it unique) when importing, or drop it from the conversion result completely (= drop the duplicate from the conversion).
Hint: Some email clients – like Apple Mail – overwrite an imported email in a folder if another email with the same message ID gets imported, even if those emails are not the same! This is not what you would usually expect or like to see happening. Keep this option enabeld to avoid headaches looking for your mysteriously disappeared emails after the import.
Hint: Olminator will first check for duplicate emails (see option above) and then check for duplicate message IDs. That means that you can first make sure that emails that are indeed identical (e.g. by copying the same email into a folder several times), get either removed or get made unique by assigning a new ID, and then the check for duplicate IDs kicks in and guarantees that no two (different) emails carry the same message ID.
Hint: One reason why the receive date can be off is the fact that Microsoft Outlook apparently changes an email's received time when importing emails from an archive rather than receiving them via mail protocol: In such cases, the received date will be set to be the timestamp of the import date and time. When importing such emails into Apple Mail after a conversion with e.g. Olminator or other converters, the following happens: Apple Mail shows emails sorted by received date by default (Microsoft Outlook uses the send date to display and sort by default) and this might be very confusing for all those emails where the received date was set to a former import date in Microsoft Outlook. Hence, Olminator allows you to 'correct' the received date during the conversion and approximate this timestamp by using the email's send date for it: if you had received an email on Dec 24th, 1999 (2 minutes after it was sent by someone), you exported the email from Outlook in 2001 and re-imported the archive into Outlook on July 04, 2014, you perhaps prefer the received date (which is lost) to be rather Dec 24th, 1999 than July 04, 2014. If that's the case, enable this option in Olminator.
Hint: By checking this option and setting the limit to a smaller number, you can effectively strip exceedingly large attachments from your emails in the output – this might be helpful to shrink inbox data in some instances.
Hint: Furthermore, it must be noted, that depending on the setting of the option "Keep original folder structure" (see above), retained attachments will either be stored "flat", i.e. all in the single directory "Retained Attachments/Emails", if that option is deselected, or will be stored in a sub-folder structure resembling your email folders' structure if that option is selected (e.g. an attachment retained from an email in a sub-folder "Inbox/Private" will be stored in the folder ".../Retained Attachments/Emails/Inbox/Private", making it easier to associate retained attachments with their originating context).
And one more thing: Olminator will remove duplicate retained attachments, i.e. attachments with the same name and byte-wise identical content, on a 'per folder' basis.
Apple Calendar 11 and newer: With version 11 of Apple Calendar, Apple has introduced a new limit of maximum .ICS file size. This limit does not exist with prior versions. If you are still using an older version of Apple Calendar (10 or below) or are using a different calendar app entirely, you may not want to have this option enabled as it will only result in many individual .ICS files being required to be imported. With the option disabled, you will get a single .ICS file containing all converted calendar events, and obviously that's easier to import.
Hint: By checking this option and setting the limit to 0, you can effectively strip all attachments from your calendar events in the output – this might be helpful to shrink calendar data in some instances.
Hint: By checking this option and setting the limit to a smaller number, you can effectively strip exceedingly large attachments from your calendar events in the output – this might be helpful to shrink calendar data in some instances.
Caveat: This situation has only been seen with Microsoft Outlook for Mac 2011 .olm files so far, if an appointment is not a result of an externally received appointment invitation, but if the appointment was created within the Outlook account itself and then sent to potential appointment invitees. In such cases, Outlook apparently assumes that the meeting organizer is implicitely defined by the account to which the corresponding calendar belongs in which the appointment was created. When exporting this information though, the implicit organizer is not explicitely written into the .olm archive by Microsoft Outlook for Mac 2011; it is actually exported by Microsoft Outlook for Mac 2016 and newer versions. To overcome this shortcoming of Microsoft Outlook for Mac 2011 you can add the missing organizer information manually in Olminator, so that during a conversion run it will be added where the information is missing in the source .olm file. If you've checked this option, you must enter your email address of the corresponding calendar account into the text field of this option.
Caveat: With Microsoft Outlook for Mac 2011 there are cases where this best possible extent may not suffice: a timezone reference may have been exported by Outlook that cannot unambigiously converted by Olminator. In such cases, Olminator will apply some internal heuristics to fill the gap, but if this logic still fails, Olminator will fall back onto the timezone you select here.
By default, the fallback timezone used is your current system timezone. You may also use this option to have Olminator ignore the timezone references exported in the .olm file and replace all start and end times of any calendar event with a timestamp translated to your fallback timezone of choice. By setting the picker of this option to 'always' you can thus normalize all start and end times of appointments to be give in the selected timezone after the conversion. (This option cannot be deselected: there's always a need to know what to do as a fallback if all else fails :)
Hint: Apple Numbers will always work with both comma or semicolon as separator and import the separator marker as a first row. Unfortunately the header row in the csv containing the field names will then become part of the table data itself rather than the header row. By deleting the first row with the marker and right-clicking the header row and chosing "Convert into table header" you can fix this manually in Apple Numbers at any time.
Hint: Having this option available in Olminator is not really necessary: You can always load the .csv file into a text editor like TextEdit and manually add or remove the "sep=#" marker if you really need it for Microsoft Excel. It can just be creating a headache if you're not aware of this feature...
Hint: If you're importing into Microsoft Excel and you happen to be in a location where your Mac's locale settings specify that the comma is used as the decimal "point"/fractional character in numbers (like very common e.g in Europe), so for example (pi = 3,14159...), then Microsoft Excel will expect the semicolon character as CSV value separator! In locales, where a point (.) is used as decimal "point"/fractional character (like e.g. in the US), comma as CSV value separator works just fine with Microsoft Excel. So in semicolon-"impacted" locales you may have to either switch Olminator to use a semicolon as CSV separator or use Olminator's separator marker option described above to "force" Microsoft Excel into loading your contacts' .csv file. It's not great, but at least it works.
Hint: Of course, with Apple Numbers, everything just works like a charm out-of-the-box – either way.
Caveat: Be aware that some contact management application like Apple Contacts impose limits on photo sizes and may not properly import a .vCard if this limit is exceeded. (see the Limitations section for more details).
Hint: Apple Numbers will always work with both comma or semicolon as separator and import the separator marker as a first row. Unfortunately the header row in the csv containing the field names will then become part of the table data itself rather than the header row. By deleting the first row with the marker and right-clicking the header row and chosing "Convert into table header" you can fix this manually in Apple Numbers at any time.
Hint: Having this option available in Olminator is not really necessary: You can always load the .csv file into a text editor like TextEdit and manually add or remove the "sep=#" marker if you really need it for Microsoft Excel. It can just be creating a headache if you're not aware of this feature...
Hint: If you're importing into Microsoft Excel and you happen to be in a location where your Mac's locale settings specify that the comma is used as the decimal "point"/fractional character in numbers (like very common e.g in Europe), so for example (pi = 3,14159...), then Microsoft Excel will expect the semicolon character as CSV value separator! In locales, where a point (.) is used as decimal "point"/fractional character (like e.g. in the US), comma as CSV value separator works just fine with Microsoft Excel. So in semicolon-"impacted" locales you may have to either switch Olminator to use a semicolon as CSV separator or use Olminator's separator marker option described above to "force" Microsoft Excel into loading your contacts' .csv file. It's not great, but at least it works.
Hint: Of course, with Apple Numbers, everything just works like a charm out-of-the-box – either way.
Caveat about duplicate attachments: Sometimes attachments with the same name (e.g. Image0001.png) may occur in independent emails or calendar appointments, as well as the same attachment file may actually appear in several related emails (e.g. when forwarded several times or if multipe copies of the same email are stored in your inbox structure). When extracting those duplicate (or presumably duplicate) attachments into one directory, Olminator will eliminate those redundant attachments if the following condition holds true: the filename is the same and the content of the suspected duplicates is exactly the same (byte-wise comparison). Olminator will then only store a single copy of the attachment.
Hint: Apple Numbers will always work with both comma or semicolon as separator and import the separator marker as a first row. Unfortunately the header row in the csv containing the field names will then become part of the table data itself rather than the header row. By deleting the first row with the marker and right-clicking the header row and chosing "Convert into table header" you can fix this manually in Apple Numbers at any time.
Hint: Having this option available in Olminator is not really necessary: You can always load the .csv file into a text editor like TextEdit and manually add or remove the "sep=#" marker if you really need it for Microsoft Excel. It can just be creating a headache if you're not aware of this feature...
Hint: If you're importing into Microsoft Excel and you happen to be in a location where your Mac's locale settings specify that the comma is used as the decimal "point"/fractional character in numbers (like very common e.g in Europe), so for example (pi = 3,14159...), then Microsoft Excel will expect the semicolon character as CSV value separator! In locales, where a point (.) is used as decimal "point"/fractional character (like e.g. in the US), comma as CSV value separator works just fine with Microsoft Excel. So in semicolon-"impacted" locales you may have to either switch Olminator to use a semicolon as CSV separator or use Olminator's separator marker option described above to "force" Microsoft Excel into loading your contacts' .csv file. It's not great, but at least it works.
Hint: Of course, with Apple Numbers, everything just works like a charm out-of-the-box – either way.
As of v2.30, Olminator also supports bulk-generating PDF or HTML files from Microsoft Outlook for Mac items stored in an .olm archive. See Generating PDF or HTML for additional information. Below are the supported options that you might tweak to influence how the conversion to PDF and HTML actually happens:
Caveat: Please be aware though that clicking the links when viewing a PDF file in your Mac's Preview app (i.e. the default PDF viewer on Mac) will only result in an error popup. This is a Preview limitation. If you are using Adobe Acrobat Viewer DC instead, clicking the links will open the corresponding attachment in the respective application as expected. By default, this option is unchecked, i.e. Olminator does not extract attachments when creating PDF.
When converting .olm file items into individual PDF or HTML files, Olmoinator needs to generate appropriate filenames that help you identify the content of such files. Up to version v3.47, Olminator used a fixed naming scheme for those files. This naming scheme used specific properties of the respective, converted items like the subject line or the sender's 'email address to create names that helped you quickly identify or guess what's within the respective PDF or HTML file. As of v3.48, you can now adapt this naming scheme to your individual needs. In order to do so, you can specify a name pattern using specific placeholders that will be replaced by the concrete values of the converted item. This can be done for email, calendar, contacts and notes items, i.e. olm-archive items that will be converted to individual files during a conversion process.
In general, a name pattern consists of a sequence of placeholders, specified within the symbols "<" and ">", e.g. "<from.address>" referring to an email's sender address, interspersed with literal symbols, e.g. underscore ("_") or other characters. The file extension will be automatically appended (e.g. ".pdf" for PDF files, ".html" for HTML files). Also, Olminator will place a sequence number right in front of the file extension to ensure no matter what name pattern you choose, each file is unique within its containing folder.
Here's an example of a name pattern as used by default for Email items: <type>_<received.year>-<received.month>-<received.day>_<received.hour>.<received.min>.<received.sec>_<from>_<subject(c40)>
Applied to a concrete email item during conversion to PDF it may yield the following filename for the respective file : email_2024-04-15_13.27.03_'Björn Goerke' <public.b.goerke@icloud.com>_Hello world_37.pdf
Hint: Characters in the name pattern or after placeholder substitution that are invalid characters for a filename on MacOS (e.g. ":") will be replaced by the underscore ("_") character automatically.
For each .olm archive item type, there's one name pattern to be defined: Email, Calendar, Contacts and Notes. By pressing the "Reset" button to the right of each input field, you can always revert to the standard name pattern. This may be helpful if you mess up the name pattern and don't know how to fix it again.
If a specific name pattern is valid, i.e. its structure and all referenced placeholders are correct, a green, circled checkmark will be displayed to the right of the pattern. If there are any invalid placeholders used, e.g. placeholders that are unknown or that contain typos, a red exlamation mark icon will be shown instead. Make sure to fix such pattern before runnning any conversion (or press "Reset" if you don't know how or fail to fix your pattern manually).
When typing a pattern, anything with the "<" and ">" characters is considered a placeholder, anything outside those symbols is considered a static literal. If a placeholder is existing and valid, its color will be green. If you're still editing the pattern and it's not completely correct, the color will be orange, if it is definitely invalid, it's red.
To help you enter valid placeholders, you can open a placeholder tag by typing "<" and then use the cursor up, cursor down, tab or return keys. The cursor up and down keys will simply pick the previous or next valid placeholder name from the list of all valid placeholders for the type of item you are currently editing. There are different placeholders available for the four item types. You can press those keys anywhere in the placeholder tag and it will replace the entire placeholder independent of what you typed there before. If you press the tab or return key, a slightly different behaviour is used: If you started the placeholder name after the "<" symbol, e.g. you typed "re" already and the cursor is positioned right after these 2 characters, pressing tab (or shift tab) will get you the next (or previous) placeholder name that starts with the placeholder prefix (here: "re"). So you will only see those placeholders that match the prefix. Pressing the return key will confirm the currently shown placeholder name, close the tag (ie. add an ">" symbol if one is still missing) and move the cursor right after the currently edited placeholder tag.
Placeholders may have different underyling "datatypes": some are strings (e.g. subject), some are numbers (e.g. received.year), some are timetamps (e.g. received, sent, or start) and some are boolean (e.g. isRecurring or isAllDay). Depending on the underlying datatype, you may add formatting information with any placeholder by putting the corresponding formatter information into parenthesis right after the placeholder name (e.g. "<received.year(04)>" or "<subject(L20)>" – the first one padding the year number to 4 digits (="4) with leading zeros (="0)" (if needed), the latter limiting the maximum output length of the subject line to 20 characters (="20") and converting all characters to lowercase (="L")). Here's the entire list of allowed formatting infos:
While allowing for a compact formatting of timestamps, the entire ISO-based formatting is super prone to human error. Olminator therefore supports an alternative, less brittle approach by exposing each datetime placeholder as an individual placeholder variable of datatype number (thus supporting the formatting as described for number datatypes above):
All these placeholders can be navigated with the up, down, tab and return key for convenience, e.g. having entered "<re" and pressing tab repeatedly will "tab" you through the list of "received.*" placeholders one after the other. By default, the formatter (02) applies for each of them, except for year where its (04) for obvious reasons.
For the sake of completeness, here's the list of all valid placeholders per item type. By and large they relate to the respective email, calendar appointment, contact information or notes items as displayed in Olminator's Viewer section. Email addresses can be referred to as the full email address (e.g. <to> might yield "'Björn Goerke' <public.b.g@icloud.com>"), while <to.display> refers to the display name (e.g. "Björn Goerke") and <to.address> corresponds to the real address part (e.g. "public.b.g@icloud.com").
Better be careful when making any edits here. Always run some tests and check the output folders whether everything meets expectations!
Hint: The number of concurrent conversion threads depends on your hardware configuration (number of CPUs/cores). It also depends on additional criteria, which need to be met, based on your conversion settings, since concurrent conversion will only kick in for independent folders during the conversion (i.e. items in a single folder will always be processed sequentially by a single thread). If you chose not to keep the original folder structure for converted emails (and hence collate them all into one flat folder), or if you extract attachments and don't keep their original folder structure, or if you are in debug mode, Olminator will only run a single conversion thread. This behaviour is independent of your selection for this option.
Caveat: Only make changes to the above settings if you experience problems importing the conversion results and you've good reason to assume that changing those settings might help.
