Re: [MlMt] Local email archiving status/options?
On 25 Jan 2021, at 10:02, Christian Bailey via mailmate wrote: Thank you! @Thomas Grundberg: Thanks to you too: “Return” works! However, a double-click does not open the message for me. It does (very helpfully) search on sender or subject if I double click either of those. That's an option in the Viewer pane of preferences. You can specify whether double click opens the message or searches. The other option will be assigned to shift-double click. Mike ___ mailmate mailing list mailmate@lists.freron.com https://lists.freron.com/listinfo/mailmate
Re: [MlMt] Local email archiving status/options?
On 25 Jan 2021, at 3:30, Fredrik Jonsson 'f...@xdeb.org' wrote: >> 2) I might end up with duplicates. Or does MM automatically no import >> duplicates? Any recommendations on de-duplication? > > You have the "Edit -> Select Duplicates" command but I have never made > use of it. Great tip. I’d seen that that’s built-in to MM. It also allows quick visual review. >> 5) Is there a way to open a message in a >> separate window? > > Select a message and go to "File -> Open Message". > > As other has mention hitting "return" also work. Thank you! @Thomas Grundberg: Thanks to you too: “Return” works! However, a double-click does not open the message for me. It does (very helpfully) search on sender or subject if I double click either of those. > I have mapped it to "O" in my custom keybindings. > > Custom keybindings and smart folders are the killer feature of > MailMate > in my opinion. I’m so excited to set these up. Most urgently I need to “Go To” each of the individual Sources’ Inbox, Archive, and Sent Items. I have totally different contexts for my mail and don’t use the combined views at all. On 25 Jan 2021, at 2:53, Thomas Grundberg 'tho...@grundberg.se' wrote: > With the message/s selected, hit return. A double-click also does it. ___ mailmate mailing list mailmate@lists.freron.com https://lists.freron.com/listinfo/mailmate
Re: [MlMt] Local email archiving status/options?
On 25 Jan 2021, at 3:30, Fredrik Jonsson wrote: 4) Just want to confirm: does MM get its address book from MacOS? Yes. I would clarify that MM pulls address from the Mac’s Contacts database, but also from the headers of existing mail messages in a (smart) folder that you specify under the “Composer” tab in the Preferences window (See: Auto-Completion Sources). This can sometimes be a little confusing, especially if your source folder is “polluted” with some incorrect or outdated email addresses. You can improve MM’s address completion behavior by flagging such addresses in a black list. Glenn P. Parker glenn.par...@comcast.net ___ mailmate mailing list mailmate@lists.freron.com https://lists.freron.com/listinfo/mailmate
Re: [MlMt] Local email archiving status/options?
Christian Bailey via mailmate 2021-01-25 3:31 wrote: 1) Which is better for importing via MM - eml or mbox? Like Bill, I also just purchased Emailchemy to covert the pst files. It offers both mbox and eml as options. I presume mbox is better if I want to import everything? MailMate does support both. The box format only creates a file per folder so for a complete export/import it most likely the better choice. 2) I might end up with duplicates. Or does MM automatically no import duplicates? Any recommendations on de-duplication? You have the "Edit -> Select Duplicates" command but I have never made use of it. 3) When I connected my Office 365 account, there were hundred of error messages as MM tried to download the Contacts, Calendar, Notes, and Tasks folders. I presume these should be unsubscribed? Yes, MailMate only does IMAP. 4) Just want to confirm: does MM get its address book from MacOS? Yes. 5) Is there a way to open a message in a separate window? Select a message and go to "File -> Open Message". As other has mention hitting "return" also work. I have mapped it to "O" in my custom keybindings. Custom keybindings and smart folders are the killer feature of MailMate in my opinion. Fredrik ___ mailmate mailing list mailmate@lists.freron.com https://lists.freron.com/listinfo/mailmate
Re: [MlMt] Local email archiving status/options?
2021-01-25 kl 3:31 skrev Christian Bailey via mailmate: > Is there a way to open a message in a separate window? With the message/s selected, hit return. A double-click also does it. -- Thomas ___ mailmate mailing list mailmate@lists.freron.com https://lists.freron.com/listinfo/mailmate
Re: [MlMt] Local email archiving status/options?
I found this message and the related [ticket](https://freron.lighthouseapp.com/projects/58672/tickets/81-archiving-to-local-folders) searching on options to import my 65 GB of offline archived email into MailMate. I’m loving the power and customizability of MailMate by the way. Switched from a PC would have switched a decade ago had I known. The lack of features in MacOS Mail.app compared to Outlook on Windows made me give up on switching twice before. I checked and my IMAP servers actually support 50 GB each and so it is feasible for me to ditch local email completely and upload everything to the servers the MM way. A few questions: 1) Which is better for importing via MM - eml or mbox? Like Bill, I also just purchased Emailchemy to covert the pst files. It offers both mbox and eml as options. I presume mbox is better if I want to import everything? 2) I might end up with duplicates. Or does MM automatically no import duplicates? Any recommendations on de-duplication? 3) When I connected my Office 365 account, there were hundred of error messages as MM tried to download the Contacts, Calendar, Notes, and Tasks folders. I presume these should be unsubscribed? 4) Just want to confirm: does MM get its address book from MacOS? I see that it has Contacts access in System Preferences-Privacy, so that’s expected. Just curious because some other mail apps (e.g., Thunderbird) actually access the Office 365 contacts directly. I wanted to confirm that MM never reads contacts from a mail server? 5) Is there a way to open a message in a separate window? Within MM, the only option appears to be to create a duplicate window of the whole application, folders and all. Some messages are poorly formatted and need to be opened in a wider window to be read. I also tried “Open in Apple Mail” but get the following error: “The operation couldn’t be completed. (MCMailErrorDomain error 1030.) // Mail was unable to open the URL “message://%3c20210124214048.d35c4121...@mail.netagw.net%3E”.” Thank you! Christian On 25 Aug 2015, at 17:59:48 EDT, Bill Cole wrote: > On 25 Aug 2015, at 7:03, Brian Scholl wrote: > >> Also, a more theoretical postscript: It seems to me that Benny's >> reluctance to pursue any sort of .mbox export […] > > I can’t speak to the IMAP-*v*-POP3 debate, but I would really love > the ability to export a series of messages as a .mbox file in the same > format that Apple Mail does. Isn't mbox great: one always has to specify a particular tool's flavor... If you want a reasonably portable mbox on your Desktop containing the messages in a MM IMAP (not "Smart") folder, it's easily done with a simple bit of shell calling the crufty old "formail" tool: cd "~/Library/Application Support/MailMate/Messages/IMAP/[account at server]/[path-to-folder]/Messages/" for fname in *.eml ; do formail < $fname ; done > ~/Desktop/Exported.mbox If you want the delimiter lines' timestamps derived from Date headers instead of now, the conversion gets more arcane and will not like improper Date headers: for fname in *.eml; do formail -a Date: < $fname ; done | sed '/^From /s/, \(..\) \(...\) \(\) \(..:..:..\) .*/ \2 \1 \4 \3/' > ~/Desktop/Exported.mbox Unfortunately, there's no sound way to get the proper delivery date into the delimiter lines unless you are an IMAP client, so Mail.app does one thing unequivocally better than formail. Also, unlike Mail.app, formail uses (CORRECTLY) the Return-Path header (if present) to derive the delimiter line address instead of Mail.app's simple use of the From message header and only adds blank lines ahead of delimiter lines on an as-needed basis. So, while MailMate won't duplicate what Apple Mail does, one can get pretty close using the MailMate message store without MailMate doing the actual work. > In addition to using SpamSieve on my Mac (which is quite good), I > maintain my own mail server (Mac OS X 10.6.8, until I am forced to > “upgrade”) It is mildly amusing to learn that, as it means I'm not alone and in respectable company. In my case the excuse is that the original Core Duo can't do 64-bit mode and so can't run 10.7 or later, and I can't bear to junk that old machine... (Tangent: Senior mail admins are insanely over-represented on this mailing list.) > and use SpamAssassin there to try to intercept as much crud as > possible *before* it gets to SpamSieve. Apple Mail produces the > perfect .mbox files for feeding to SpamAssassin’s spam-learning > routines, so periodically I have to haul Mail out, select all the junk > that SpamAssassin needs to learn how to intercept, and File > Save > As… (raw source) to a file that I can then drag to the server and > run learnspam against. I'm surprised that no one in this thread has yet mentioned the simple ability to select messages in a MM message list and drag them to a Finder window: a very fast way to create a file-per-message offline local archive. As someone who has retained
Re: [MlMt] Local email archiving status/options?
On 27 Aug 2015, at 22:27, Michael Tsai wrote: On Aug 27, 2015, at 3:03 PM, Muster Hans mus...@sture.ch wrote: I tried both the EF bundle method and dragging to the Finder. The EF bundle method was painfully slow, though that was not helped by EagleFiler generating a notification for every single message. I tried turning that off in System Preferences / Notifications but they still kept on coming. I've just discovered an Esoteric Preference for that, but the documentation doesn't seem to match the behaviour I saw. The MailMate bundle is probably always going to be slower than drag-and-drop because it compiles and runs a separate AppleScript command for each message. This is also why you get a notification per message rather than one for the batch. Understood. You can adjust in System Preferences how notifications are displayed, but not whether they are posted or recorded. It may be that the system kept displaying notifications after you had turned it off because it was still processing old notifications. That could indeed be the case. To stop the notifications entirely, you would need to use the DisableNotificationCenter esoteric preference: http://c-command.com/eaglefiler/help/esoteric-preferences Done, and I will monitor this. If you have further questions about this, please feel free to contact me at eaglefi...@c-command.com. In contrast, 3,800 messages went into EF via dragging in about 6 minutes. It's taking 6 minutes because there are so many separate files. If you import from Apple Mail, EagleFiler would generate a mbox file and do the import in 30 seconds or so. My guess is that the new MailMate Export bundle would work similarly. I was actually quite pleased with 6 minutes. It's not something I plan on doing very often. However, I ran into a real show stopper for me - EF doesn't support UTF-8. From DefaultMessageEncoding at http://c-command.com/eaglefiler/manual#esoteric-preferences When a message doesn’t specify which text encoding it uses, EagleFiler has to guess. An incorrect guess may cause the message to display using strange accents or garbage characters. By default EagleFiler guesses MacRoman, but you can change it to guess ISO Latin 1 instead. EagleFiler does support UTF-8. For example, the message that you just sent declares itself as: Content-Type: text/plain; charset=utf-8; Format=flowed and the Unicode characters at the end display properly in EagleFiler (as does Grüsse). The DefaultMessageEncoding esoteric preference only applies when the message (improperly) uses non-ASCII characters without specifying what encoding they are in. I don't think I've ever seen a message that did this using UTF-8. Generally, it is older mail clients that would, e.g., send the message as MacRoman with no explicit encoding, so that it would only display properly if the client knew to assume that it was in MacRoman. This was back when apps didn't support Unicode, so it shouldn't be an issue with modern mail clients. However, if you do come across a message that is using UTF-8 without specifying it, you could set the esoteric preference accordingly: x-eaglefiler://default?k=DefaultMessageEncodingv=utf-8 This resolves a non-mail related artefact I have been seeing, so thanks for that - unfortunately this isn't in the current EagleFiler manual. I have a load of mails in German where each and every accented character gets mangled by EF. E.g. Freundliche Grüsse (~=Regards) displays in EF as Freundliche Gr=FCsse, and it's a similar disaster with other accented characters. Please send one of the problem .eml files to eaglefi...@c-command.com so that I can look into this. Will do, though I've now stumbled across a different problem. It appears that any mail containing Unicode characters gets encoded. Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 Expected behaviour when there are still 7 bit mail gateways out there, but when imported into EagleFiler I just see the encoded block. Thanks very much for your prompt response. It is much appreciated. ___ mailmate mailing list mailmate@lists.freron.com http://lists.freron.com/listinfo/mailmate
Re: [MlMt] Local email archiving status/options?
On Aug 28, 2015, at 4:55 AM, Muster Hans mus...@sture.ch wrote: However, if you do come across a message that is using UTF-8 without specifying it, you could set the esoteric preference accordingly: x-eaglefiler://default?k=DefaultMessageEncodingv=utf-8 This resolves a non-mail related artefact I have been seeing, so thanks for that - unfortunately this isn't in the current EagleFiler manual. Non-mail? It's not in the manual because it has never come up before. I would be interested to see a message for which it's necessary. It appears that any mail containing Unicode characters gets encoded. Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 Expected behaviour when there are still 7 bit mail gateways out there, but when imported into EagleFiler I just see the encoded block. EagleFiler doesn't change the content transfer encoding of the message, and my guess is that MailMate doesn't either. It was probably sent that way. If you are seeing the encoded block in EagleFiler, perhaps this is because you have Message View Raw Source checked. This would also cause you to see words with equals signs instead of accented characters, because it would be showing the quoted printable source rather than the decoded Unicode. --Michael -- Michael Tsai C-Command Software ___ mailmate mailing list mailmate@lists.freron.com http://lists.freron.com/listinfo/mailmate
Re: [MlMt] Local email archiving status/options?
On 25 Aug 2015, at 23:59, Bill Cole wrote: Isn't mbox great: one always has to specify a particular tool's flavor... Yes, this is why I've been reluctant with respect to implementing mbox export. Thanks for the `formail` trick. Now I can just blame an external utility. (Tangent: Senior mail admins are insanely over-represented on this mailing list.) Maybe they are the only ones still using mailing lists. I'm still considering alternatives which include a web interface. In particular, [GroupServer](http://groupserver.org) and [Groups.io](https://groups.io/static/features). Another approach I've played with but not really exercised hard is a zombie IMAP Account permanently offline as a local archive. The connection settings don't work and never have, but I can create folders and subfolders and MM creates the directories just as it would for a normal account. Benny has vaguely warned that this might not be a reliable approach, but I think that's only because it has no backend and ultimately would be lost if MM decided its local cache of messages was not to be trusted. Yes, also the fact that moving a message from an online account to an offline account doesn't work as the user might expect. MailMate is very strict about not deleting anything from a source account until **after** the destination is synchronized (the message is uploaded). This never happens for an offline IMAP account. Tags may not work also... They work, but are also lost if the MailMate database is corrupted. This might be improved when I finally get around to mapping tags to OS X file metadata. -- Benny ___ mailmate mailing list mailmate@lists.freron.com http://lists.freron.com/listinfo/mailmate
Re: [MlMt] Local email archiving status/options?
On 25 Aug 2015, at 19:26, Paul Hoffman wrote: A big +1 for a new feature of right-click-on-mailbox - Export This Mailbox with at least .mbox as one of the output formats. I'm fine if that is the only output format, but maildir would be useful as well. In the latest test version I've included a bundle named “Export” which uses the `formail` trick described by Bill Cole to create an mbox file. It has a setting which can be used to specify a destination folder (see the “Command ▸ Export” menu). If the destination is the Desktop and you archive an email located in “Archive/2013” in an account named “My Account” then it would result in the email being appended to this file: ~/Desktop/My Account/Archive/2013.mbox That is, if it works as expected. In theory, you could select all emails in an account and have them exported to mbox-files; one mbox file for each mailbox. (I don't know how this actually performs since I haven't tried.) The bundle can be used as a starting point if you want to do something more advanced. -- Benny ___ mailmate mailing list mailmate@lists.freron.com http://lists.freron.com/listinfo/mailmate
Re: [MlMt] Local email archiving status/options?
On 27 Aug 2015, at 8:29, Benny Kjær Nielsen wrote: In the latest test version I've included a bundle named “Export” which uses the `formail` trick described by Bill Cole to create an mbox file. It has a setting which can be used to specify a destination folder (see the “Command ▸ Export” menu). If the destination is the Desktop and you archive an email located in “Archive/2013” in an account named “My Account” then it would result in the email being appended to this file: ~/Desktop/My Account/Archive/2013.mbox That is, if it works as expected. In theory, you could select all emails in an account and have them exported to mbox-files; one mbox file for each mailbox. (I don't know how this actually performs since I haven't tried.) Benny, You are awesome! Thank you, thank you, thank you for this function! It works perfectly with learnspam and now I can shelve Apple Mail forever. FWIW, selecting all the mail in my “Junk” top-level folder and running the export command on it produces one file inside a folder for each account, which is quite sufficient for my needs. -- ___ mailmate mailing list mailmate@lists.freron.com http://lists.freron.com/listinfo/mailmate
Re: [MlMt] Local email archiving status/options?
On 26 Aug 2015, at 1:33, Brian Scholl wrote: (And I'm also glad to learn from Bill Cole about the formail shell option to produce the .mbox file directly; I'll play with the date stuff and see how close I can get with that too.) Try out the new Export bundle if you go down this path. But I do hold out some hope that maybe we can still convince Benny to just hold his nose and provide an IMAP-folder-to-.mbox command in MM itself. Well, the `formail` command meant I did not have to deal with the `mbox` format myself. Maybe this will happen if we all just keep politely asking for this -- especially if we intimate that otherwise we will be using Mail.app as a MM utility, and/or that we will be poking around in MM's local files despite the warnings? :-) Bill Cole wrote: As someone who has retained email for 20+ years including a substantial spam corpus (it's a professional focus) I share the desire for a local, integrated, purely private, and reliable mail archive. That seems like another great example. Benny, would you really just recommend that Bill keep 20 years of SPAM online? (I'm worried that the answer will just be an enthusiastic 'yes!', but that seems like an unacceptable option to me.) My answer is that I don't recommend that, but this is a special case and Bill is able to work around this limitation of MailMate. As Bill notes MailMate can use quite a lot of resources when used for very large message stores. Even though I have reports of more than 1 million emails handled by MailMate I didn't design MailMate for this use case. I really do believe most users should stick to a clean IMAP setup (myself included). I don't want to make it too easy to avoid that, but I'm aware that I cannot prevent users from working around this limitation and as you have seen I also answer questions related to it. -- Benny ___ mailmate mailing list mailmate@lists.freron.com http://lists.freron.com/listinfo/mailmate
Re: [MlMt] Local email archiving status/options?
On 26 Aug 2015, at 1:33, Brian Scholl wrote: Clearly there are plenty of workarounds to try for local-only archiving, so I'll make something work. I'm still hesitant to try any of the local IMAP server options (and I have great server-side SPAM handling already through my university), but it sounds to me like my best bet for creating a long-term-storage archive might just be to export .eml files directly from MM (via the EF bundle, via dragging-to-the-finder, or by stealing them from MM's private ~/Library/ directory) and then have EagleFiler translate/collate them into an .mbox archive for long term storage. As long as that will work for folders of ~ 1000 messages at a time (and will preserve the dates, etc.), that sounds fine. I tried both the EF bundle method and dragging to the Finder. The EF bundle method was painfully slow, though that was not helped by EagleFiler generating a notification for every single message. I tried turning that off in System Preferences / Notifications but they still kept on coming. I've just discovered an Esoteric Preference for that, but the documentation doesn't seem to match the behaviour I saw. In contrast, 3,800 messages went into EF via dragging in about 6 minutes. However, I ran into a real show stopper for me - EF doesn't support UTF-8. From DefaultMessageEncoding at http://c-command.com/eaglefiler/manual#esoteric-preferences When a message doesn’t specify which text encoding it uses, EagleFiler has to guess. An incorrect guess may cause the message to display using strange accents or garbage characters. By default EagleFiler guesses MacRoman, but you can change it to guess ISO Latin 1 instead. I have a load of mails in German where each and every accented character gets mangled by EF. E.g. Freundliche Grüsse (~=Regards) displays in EF as Freundliche Gr=FCsse, and it's a similar disaster with other accented characters. Try exporting the following to EF to see what I mean: Here's some unicode: ☺, ☻, ✌, ✍, ✎, ✉, ☀, ☃, ☁, ☂, ★, ☆, ☮, ☯, 〠, ☎, ☏, ♕, ❏, ☐, ☑, ☒, ✓, ✗, ¢, €, £, ❤, ❣, ❦, ♣, ♤, ♥, ♦, ♧, ►, ❝, ❞, ☜, ☝, ☞, ☟, ☚, ☛, ☹, త, ☣, ☠ ___ mailmate mailing list mailmate@lists.freron.com http://lists.freron.com/listinfo/mailmate
Re: [MlMt] Local email archiving status/options?
On 26 Aug 2015, at 1:33, Brian Scholl wrote: Clearly there are plenty of workarounds to try for local-only archiving, so I'll make something work. I'm still hesitant to try any of the local IMAP server options (and I have great server-side SPAM handling already through my university), but it sounds to me like my best bet for creating a long-term-storage archive might just be to export .eml files directly from MM (via the EF bundle, via dragging-to-the-finder, or by stealing them from MM's private ~/Library/ directory) and then have EagleFiler translate/collate them into an .mbox archive for long term storage. As long as that will work for folders of ~ 1000 messages at a time (and will preserve the dates, etc.), that sounds fine. I tried both the EF bundle method and dragging to the Finder. The EF bundle method was painfully slow, though that was not helped by EagleFiler generating a notification for every single message. I tried turning that off in System Preferences / Notifications but they still kept on coming. I've just discovered an Esoteric Preference for that, but the documentation doesn't seem to match the behaviour I saw. In contrast, 3,800 messages went into EF via dragging in about 6 minutes. However, I ran into a real show stopper for me - EF doesn't support UTF-8. From DefaultMessageEncoding at http://c-command.com/eaglefiler/manual#esoteric-preferences When a message doesn’t specify which text encoding it uses, EagleFiler has to guess. An incorrect guess may cause the message to display using strange accents or garbage characters. By default EagleFiler guesses MacRoman, but you can change it to guess ISO Latin 1 instead. I have a load of mails in German where each and every accented character gets mangled by EF. E.g. Freundliche Grüsse (~=Regards) displays in EF as Freundliche Gr=FCsse, and it's a similar disaster with other accented characters. Try exporting the following to EF to see what I mean: Here's some unicode: ☺, ☻, ✌, ✍, ✎, ✉, ☀, ☃, ☁, ☂, ★, ☆, ☮, ☯, 〠, ☎, ☏, ♕, ❏, ☐, ☑, ☒, ✓, ✗, ¢, €, £, ❤, ❣, ❦, ♣, ♤, ♥, ♦, ♧, ►, ❝, ❞, ☜, ☝, ☞, ☟, ☚, ☛, ☹, త, ☣, ☠ ___ mailmate mailing list mailmate@lists.freron.com http://lists.freron.com/listinfo/mailmate
Re: [MlMt] Local email archiving status/options?
On Aug 27, 2015, at 3:03 PM, Muster Hans mus...@sture.ch wrote: I tried both the EF bundle method and dragging to the Finder. The EF bundle method was painfully slow, though that was not helped by EagleFiler generating a notification for every single message. I tried turning that off in System Preferences / Notifications but they still kept on coming. I've just discovered an Esoteric Preference for that, but the documentation doesn't seem to match the behaviour I saw. The MailMate bundle is probably always going to be slower than drag-and-drop because it compiles and runs a separate AppleScript command for each message. This is also why you get a notification per message rather than one for the batch. You can adjust in System Preferences how notifications are displayed, but not whether they are posted or recorded. It may be that the system kept displaying notifications after you had turned it off because it was still processing old notifications. To stop the notifications entirely, you would need to use the DisableNotificationCenter esoteric preference: http://c-command.com/eaglefiler/help/esoteric-preferences If you have further questions about this, please feel free to contact me at eaglefi...@c-command.com. In contrast, 3,800 messages went into EF via dragging in about 6 minutes. It's taking 6 minutes because there are so many separate files. If you import from Apple Mail, EagleFiler would generate a mbox file and do the import in 30 seconds or so. My guess is that the new MailMate Export bundle would work similarly. However, I ran into a real show stopper for me - EF doesn't support UTF-8. From DefaultMessageEncoding at http://c-command.com/eaglefiler/manual#esoteric-preferences When a message doesn’t specify which text encoding it uses, EagleFiler has to guess. An incorrect guess may cause the message to display using strange accents or garbage characters. By default EagleFiler guesses MacRoman, but you can change it to guess ISO Latin 1 instead. EagleFiler does support UTF-8. For example, the message that you just sent declares itself as: Content-Type: text/plain; charset=utf-8; Format=flowed and the Unicode characters at the end display properly in EagleFiler (as does Grüsse). The DefaultMessageEncoding esoteric preference only applies when the message (improperly) uses non-ASCII characters without specifying what encoding they are in. I don't think I've ever seen a message that did this using UTF-8. Generally, it is older mail clients that would, e.g., send the message as MacRoman with no explicit encoding, so that it would only display properly if the client knew to assume that it was in MacRoman. This was back when apps didn't support Unicode, so it shouldn't be an issue with modern mail clients. However, if you do come across a message that is using UTF-8 without specifying it, you could set the esoteric preference accordingly: x-eaglefiler://default?k=DefaultMessageEncodingv=utf-8 I have a load of mails in German where each and every accented character gets mangled by EF. E.g. Freundliche Grüsse (~=Regards) displays in EF as Freundliche Gr=FCsse, and it's a similar disaster with other accented characters. Please send one of the problem .eml files to eaglefi...@c-command.com so that I can look into this. --Michael -- Michael Tsai C-Command Software ___ mailmate mailing list mailmate@lists.freron.com http://lists.freron.com/listinfo/mailmate
Re: [MlMt] Local email archiving status/options?
i am not so much interested in pop3 as i am in local storage, preferably mh. sorry, but you seem to be asking for votes. randy ___ mailmate mailing list mailmate@lists.freron.com http://lists.freron.com/listinfo/mailmate
Re: [MlMt] Local email archiving status/options?
As far as I am aware the mail component of the $20 Apple OS Server product requires a fixed IP address, plus appropriate DNS entries of course. On 25 Aug 2015, at 19:14, Helen Holzgrafe wrote: We also use Apple Server mail with Mailmate. Because there are two of us we use an older mac as a designated server machine, but you can use Apple server on your own machine to host your own imap mail and use your own disk drive as a direct mail archive. For $20 for Apple Server software and possibly a cheap outboard disk drive (that you probably have already), you can avoid limits pretty much anywhere. We have our own mail domain, but you can use a mix of your own accounts just on your server and real accounts like Google mail and move messages between them. We were using Postbox (and Eudora before that) and .mbox files. Then, my .mbox files got bitrot of some kind and ultimately Postbox could not read many of them. It took much work to translate more than 34 messages archived for 20 years that were somewhat garbled, but I did. On 25 Aug 2015, at 7:58, David O'Donnell wrote: On 25 Aug 2015, at 7:03, Brian Scholl wrote: Also, a more theoretical postscript: It seems to me that Benny's reluctance to pursue any sort of .mbox export […] I can’t speak to the IMAP-*v*-POP3 debate, but I would really love the ability to export a series of messages as a .mbox file in the same format that Apple Mail does. In addition to using SpamSieve on my Mac (which is quite good), I maintain my own mail server (Mac OS X 10.6.8, until I am forced to “upgrade”) and use SpamAssassin there to try to intercept as much crud as possible *before* it gets to SpamSieve. Apple Mail produces the perfect .mbox files for feeding to SpamAssassin’s spam-learning routines, so periodically I have to haul Mail out, select all the junk that SpamAssassin needs to learn how to intercept, and File Save As… (raw source) to a file that I can then drag to the server and run learnspam against. OooH! A tactic I had not realized I can use! Thanks, I will start doing doing this right away! -Helen ___ mailmate mailing list mailmate@lists.freron.com http://lists.freron.com/listinfo/mailmate ___ mailmate mailing list mailmate@lists.freron.com http://lists.freron.com/listinfo/mailmate
Re: [MlMt] Local email archiving status/options?
A big +1 for a new feature of right-click-on-mailbox - Export This Mailbox with at least .mbox as one of the output formats. I'm fine if that is the only output format, but maildir would be useful as well. --Paul Hoffman ___ mailmate mailing list mailmate@lists.freron.com http://lists.freron.com/listinfo/mailmate
Re: [MlMt] Local email archiving status/options?
For whatever it's worth, I use http://offlineimap.org to archive email locally but keep it on the server, and then unsubscribe from the folder in MailMate. I also do not care about storage costs, I just want my email in an interchange format. This works for me. It brings down messages in well-formatted maildir, which can then be easily converted to mbox. I think a lot of reasonable email archive type programs also support maildir though. On 25 Aug 2015, at 13:26, Paul Hoffman wrote: A big +1 for a new feature of right-click-on-mailbox - Export This Mailbox with at least .mbox as one of the output formats. I'm fine if that is the only output format, but maildir would be useful as well. --Paul Hoffman ___ mailmate mailing list mailmate@lists.freron.com http://lists.freron.com/listinfo/mailmate ___ mailmate mailing list mailmate@lists.freron.com http://lists.freron.com/listinfo/mailmate
Re: [MlMt] Local email archiving status/options?
On 25 Aug 2015, at 7:03, Brian Scholl wrote: Also, a more theoretical postscript: It seems to me that Benny's reluctance to pursue any sort of .mbox export […] I can’t speak to the IMAP-*v*-POP3 debate, but I would really love the ability to export a series of messages as a .mbox file in the same format that Apple Mail does. In addition to using SpamSieve on my Mac (which is quite good), I maintain my own mail server (Mac OS X 10.6.8, until I am forced to “upgrade”) and use SpamAssassin there to try to intercept as much crud as possible *before* it gets to SpamSieve. Apple Mail produces the perfect .mbox files for feeding to SpamAssassin’s spam-learning routines, so periodically I have to haul Mail out, select all the junk that SpamAssassin needs to learn how to intercept, and File Save As… (raw source) to a file that I can then drag to the server and run learnspam against. -- ___ mailmate mailing list mailmate@lists.freron.com http://lists.freron.com/listinfo/mailmate
Re: [MlMt] Local email archiving status/options?
We also use Apple Server mail with Mailmate. Because there are two of us we use an older mac as a designated server machine, but you can use Apple server on your own machine to host your own imap mail and use your own disk drive as a direct mail archive. For $20 for Apple Server software and possibly a cheap outboard disk drive (that you probably have already), you can avoid limits pretty much anywhere. We have our own mail domain, but you can use a mix of your own accounts just on your server and real accounts like Google mail and move messages between them. We were using Postbox (and Eudora before that) and .mbox files. Then, my .mbox files got bitrot of some kind and ultimately Postbox could not read many of them. It took much work to translate more than 34 messages archived for 20 years that were somewhat garbled, but I did. On 25 Aug 2015, at 7:58, David O'Donnell wrote: On 25 Aug 2015, at 7:03, Brian Scholl wrote: Also, a more theoretical postscript: It seems to me that Benny's reluctance to pursue any sort of .mbox export […] I can’t speak to the IMAP-*v*-POP3 debate, but I would really love the ability to export a series of messages as a .mbox file in the same format that Apple Mail does. In addition to using SpamSieve on my Mac (which is quite good), I maintain my own mail server (Mac OS X 10.6.8, until I am forced to “upgrade”) and use SpamAssassin there to try to intercept as much crud as possible *before* it gets to SpamSieve. Apple Mail produces the perfect .mbox files for feeding to SpamAssassin’s spam-learning routines, so periodically I have to haul Mail out, select all the junk that SpamAssassin needs to learn how to intercept, and File Save As… (raw source) to a file that I can then drag to the server and run learnspam against. OooH! A tactic I had not realized I can use! Thanks, I will start doing doing this right away! -Helen ___ mailmate mailing list mailmate@lists.freron.com http://lists.freron.com/listinfo/mailmate
Re: [MlMt] Local email archiving status/options?
On 25 Aug 2015, at 10:58, David O'Donnell wrote: On 25 Aug 2015, at 7:03, Brian Scholl wrote: Also, a more theoretical postscript: It seems to me that Benny's reluctance to pursue any sort of .mbox export […] I can’t speak to the IMAP-*v*-POP3 debate, but I would really love the ability to export a series of messages as a .mbox file in the same format that Apple Mail does. Isn't mbox great: one always has to specify a particular tool's flavor... If you want a reasonably portable mbox on your Desktop containing the messages in a MM IMAP (not Smart) folder, it's easily done with a simple bit of shell calling the crufty old formail tool: cd ~/Library/Application Support/MailMate/Messages/IMAP/[account@server]/[path-to-folder]/Messages/ for fname in *.eml ; do formail $fname ; done ~/Desktop/Exported.mbox If you want the delimiter lines' timestamps derived from Date headers instead of now, the conversion gets more arcane and will not like improper Date headers: for fname in *.eml; do formail -a Date: $fname ; done | sed '/^From /s/, \(..\) \(...\) \(\) \(..:..:..\) .*/ \2 \1 \4 \3/' ~/Desktop/Exported.mbox Unfortunately, there's no sound way to get the proper delivery date into the delimiter lines unless you are an IMAP client, so Mail.app does one thing unequivocally better than formail. Also, unlike Mail.app, formail uses (CORRECTLY) the Return-Path header (if present) to derive the delimiter line address instead of Mail.app's simple use of the From message header and only adds blank lines ahead of delimiter lines on an as-needed basis. So, while MailMate won't duplicate what Apple Mail does, one can get pretty close using the MailMate message store without MailMate doing the actual work. In addition to using SpamSieve on my Mac (which is quite good), I maintain my own mail server (Mac OS X 10.6.8, until I am forced to “upgrade”) It is mildly amusing to learn that, as it means I'm not alone and in respectable company. In my case the excuse is that the original Core Duo can't do 64-bit mode and so can't run 10.7 or later, and I can't bear to junk that old machine... (Tangent: Senior mail admins are insanely over-represented on this mailing list.) and use SpamAssassin there to try to intercept as much crud as possible *before* it gets to SpamSieve. Apple Mail produces the perfect .mbox files for feeding to SpamAssassin’s spam-learning routines, so periodically I have to haul Mail out, select all the junk that SpamAssassin needs to learn how to intercept, and File Save As… (raw source) to a file that I can then drag to the server and run learnspam against. I'm surprised that no one in this thread has yet mentioned the simple ability to select messages in a MM message list and drag them to a Finder window: a very fast way to create a file-per-message offline local archive. As someone who has retained email for 20+ years including a substantial spam corpus (it's a professional focus) I share the desire for a local, integrated, purely private, and reliable mail archive. Even though I have my own Dovecot server running on a machine in the same room as my main desktop, I don't keep my biggest archive there. Instead, after years of working with various tools on a semi-converted pile of Eudora almost-mbox files, I finally bought a license for Emailchemy (http://www.weirdkid.com/products/emailchemy/index.html) a tool that can actually recover and convert Eudora's quirky Classic Mac format (CR-delimited mboxes with resource fork indexing and split attachments pointed to by HFS CNIDs) as well as just about any other mail format one might have into a variety of file-per-message and standard mbox formats INCLUDING a maildir-like tree with a trivial read-only IMAP interface meant to be used as a Import Server. Since my old archive is just that, I had Emailchemy do the conversion and run the Import Server for long enough to have MailMate import the whole tree as a new IMAP account. That account has been in offline mode in MM for a couple of years now, happily challenging the robustness of MailMate's indexing searching capabilities as a huge collection of very weird mail, much of it intentionally and maliciously in violation of any known standard. Works marvelously, except that MM eats a lot of RAM (unavoidable with 400k+ messages) and is a bit sluggish for some searches. Another approach I've played with but not really exercised hard is a zombie IMAP Account permanently offline as a local archive. The connection settings don't work and never have, but I can create folders and subfolders and MM creates the directories just as it would for a normal account. Benny has vaguely warned that this might not be a reliable approach, but I think that's only because it has no backend and ultimately would be lost if MM decided its local cache of messages was not to be trusted. Tags may not work also... I think to some degree the
Re: [MlMt] Local email archiving status/options?
On 25 Aug 2015, at 13:25, Muster Hans wrote: As far as I am aware the mail component of the $20 Apple OS Server product requires a fixed IP address, plus appropriate DNS entries of course. For direct incoming delivery to mail addresses your own domain, yes: as it is with any SMTP server. However, if you just want Server for the IMAP side of the mail service, i.e. somewhere to stash mail locally so you can remove it from dependence on an ISP's IMAP service, Server is happy to turn on its Mail service with nothing but a private IP (192.168.*, 10.* etc.) and never receive mail via SMTP. That's a bit wasteful of resources (i.e. you're running Postfix for no reason...) but it does give one a working Dovecot IMAP instance without having to read the copious Dovecot docs to figure out how much of it is entirely unneeded for a trivial deployment. ___ mailmate mailing list mailmate@lists.freron.com http://lists.freron.com/listinfo/mailmate
Re: [MlMt] Local email archiving status/options?
On 25 Aug 2015, at 23:59, Bill Cole wrote: On 25 Aug 2015, at 13:25, Muster Hans wrote: As far as I am aware the mail component of the $20 Apple OS Server product requires a fixed IP address, plus appropriate DNS entries of course. For direct incoming delivery to mail addresses your own domain, yes: as it is with any SMTP server. However, if you just want Server for the IMAP side of the mail service, i.e. somewhere to stash mail locally so you can remove it from dependence on an ISP's IMAP service, Server is happy to turn on its Mail service with nothing but a private IP (192.168.*, 10.* etc.) and never receive mail via SMTP. That's a bit wasteful of resources (i.e. you're running Postfix for no reason...) but it does give one a working Dovecot IMAP instance without having to read the copious Dovecot docs to figure out how much of it is entirely unneeded for a trivial deployment. That sounds useful thanks, and with that knowledge I'm inclined to do battle with OS X Server again :-) ___ mailmate mailing list mailmate@lists.freron.com http://lists.freron.com/listinfo/mailmate
Re: [MlMt] Local email archiving status/options?
On 25 Aug 2015, at 12:33, Brian Scholl wrote: (I will also say that the degree of transparency available about the status of MM's development -- in Benny's many quick replies in this list, plus the issue tracker -- seems like a *huge* plus.) My Inbox seems to tell a story about an increase of 1-2 emails per day of “open” issues... I am facing a single roadblock, though, that is the lack of support for any local message archiving. Having read the list archives extensively, I have the following two impressions: 1. A good number of people need/want this, in some form or another. [...] 2. But the probability of Benny adding this option anytime in the foreseeable future seems to be somewhere between very low and zero. [...] Your impressions are (more or less) correct. [work flow] So my plea to the list members is just this: what are my best options for doing this? 1. LOCAL EXPORT? Can I somehow export an IMAP folder from MM to any form of locally-accessible file/archive (such as an .mbox file)? It appears that this isn't possible, and this is what Benny isn't too keen on adding. That is not correct. I have simply never implemented it. *Partly* because I suspect I'll have issues with the `.mbox` format which is not a well defined standard. I'm afraid no matter how I implement it then I'll have reports about it failing to be imported in some other app and in the end I'll need options for every variant of the `.mbox` format. But I won't really know before it's implemented. It might not be that bad. Also, I mainly see the `.mbox` format as being about interoperability. From the perspective of MailMate, it's an obsolete file format. 2. SNEAKY OFFLINE ACCESS TO MM'S LOCAL IMAP FILES? *Don't do that.* Emails are saved in a nice folder hierarchy in standard raw form. One file per email. But you should never move, delete, or assume anything about these files. It's just nice to know if something goes horribly wrong and you need direct access to the emails. (You won't of course, because they should all be on IMAP ;-) ). 3. RUNNING MY OWN MAIL SERVER? Cons: Technically hard and if done on the local disk then it'll double the space usage. Pro: It works. 4. DIRECT EXPORTING TO EXTERNAL DATABASES/PROGRAMS? You can enable some of these programs in the Bundles preferences pane. The main problem is to keep the mailbox name, but something could perhaps be done about that. With the latest test version of MailMate you also have the option of simply exporting `.eml` files since emails can be searched via Spotlight. You could use mailbox rules to automatically save emails to a folder and delete them on IMAP, but (again) mailbox names might be a problem. It would be harder (but more flexible) to create a bundle command to do this. In fact, I should probably consider providing that by default. 5. LOCAL ARCHIVING TO MBOX FILES VIA A DIFFERENT EMAIL CLIENT? I'll just skip that one. I really am keen to start taking advantage of all MM has to offer, but having some form of local archive is really non-negotiable for me. Well, you already know that I always question this starting point... :-) I think your best options are: 1. Force me to make exporting `.eml` files easier and then use Spotlight (or the Finder) to search locally archived emails. 2. Setup a dummy IMAP account in MailMate which is always offline and then see if you can use some variant of what I suggest in [this ticket](https://freron.lighthouseapp.com/projects/58672/tickets/733). I hope this helps a bit. -- Benny ___ mailmate mailing list mailmate@lists.freron.com http://lists.freron.com/listinfo/mailmate
Re: [MlMt] Local email archiving status/options?
Also, a more theoretical postscript: It seems to me that Benny's reluctance to pursue any sort of .mbox export or local folder option stems from the notion that such things are intrinsically in opposition to the entire notion/purpose of IMAP. For example, in one of the ticket replies about such things once upon a time, he wrote: MailMate really is IMAP only and I don't have any current plans to change that. Essentially (if you think about it), 'On My Mac' support is the same as supporting POP3. Messages are only temporarily stored on the server. That doesn't seem right to me. Embracing the IMAP worldview but then also limiting the size and complexity of online accounts by periodically allowing them to be culled to local-only long-term-storage archives doesn't feel the same to me as just using POP3 in a different way. Conversely, it seems like allowing for a local .mbox export (or something like that) in MM wouldn't be some sort of betrayal of its underlying nature. Rather, it would just be a way for users to adapt true day-to-day IMAP usage to a longer-term archiving practice. (A concrete example: I teach classes at a university, and during each semester I will accrete huge online IMAP folders with emails relating to those classes. But then once the relevant semester has finished, I just hate the idea of keeping those folders online forever. Even just the sheer *number* of such folders would become awkward and distracting over time, not to mention the messages they contain. But I also don't just want to delete those messages forever -- since maybe once per year I'll have a need to dive into a previous semester's folders to find something. So this is practice some sort of betrayal of how I'm supposed to use IMAP?) Do others feel similarly? Am I just thinking about this the wrong way? -Brian Brian Scholl wrote: Please pardon the length of this plea for help, and please pardon my naivete. (I am switching not only from another client to MailMate, but from POP to IMAP at the same time -- with all the changes in workflow and mindset that entails -- and I am probably under the grip of some false assumptions.) I have already convinced myself that I must switch to MM for all sorts of reasons (most of them involving customizability), so that is now a foregone conclusion. (I will also say that the degree of transparency available about the status of MM's development -- in Benny's many quick replies in this list, plus the issue tracker -- seems like a *huge* plus.) I am facing a single roadblock, though, that is the lack of support for any local message archiving. Having read the list archives extensively, I have the following two impressions: 1. A good number of people need/want this, in some form or another. (It keeps coming up on the list semi-regularly, and by my count it has occasioned at least 6 different tickets over years, etc.) For some people, this is a need driven by server/account size constraints. For others, it is simply a workflow-related preference. And this has led at least some users to cook up fairly obscure, complicated, and/or kluge-y solutions (such as Fredrik Jonsson's method of setting up and running a local IMAP server to implement local archiving). 2. But the probability of Benny adding this option anytime in the foreseeable future seems to be somewhere between very low and zero. (He has generally flagged these sorts of tickets as 'bluesky'.) I have the impression that this is not because it's especially technically challenging, but because he's philosophically opposed to it. (Most of his replies in the relevant list threads involve trying to get people to stop wanting this in the first place, and/or to ask for IMAP quota increases instead, etc.) I don't resent this perspective at all, but I nevertheless need some workaround since this is nonnegotiable for me -- and the purpose of this message is to try to clarify my options. What I want, in brief, is this: I want to use MM to sort my incoming mail into various IMAP folders (probably about 20 of them, and probably using some combination of filters/rules and manual message-moving via custom keybindings). Then I'll interact with my mail on a daily basis via those folders along with many additional MM Smart folders. Then, every so often (e.g. once per year) -- when some of those IMAP folders get huge and/or old, I want to archive them to some form of local-only folder/storage, such that (1) I can then mass-delete all of the messages from those IMAP folders (so that there are no longer any copies stored online), at which point those particular folders will just start filling up again from scratch with new incoming mail; but (2) I can still occasionally browse the local-only archived messages somehow (even if this is done in some other program such as DevonThink or EagleFiler -- though obviously it would be nice to be able to do this in MM itself). I should also
Re: [MlMt] Local email archiving status/options?
Thanks to everyone for the quick and very helpful responses. A few thoughts and followup questions: Clearly there are plenty of workarounds to try for local-only archiving, so I'll make something work. I'm still hesitant to try any of the local IMAP server options (and I have great server-side SPAM handling already through my university), but it sounds to me like my best bet for creating a long-term-storage archive might just be to export .eml files directly from MM (via the EF bundle, via dragging-to-the-finder, or by stealing them from MM's private ~/Library/ directory) and then have EagleFiler translate/collate them into an .mbox archive for long term storage. As long as that will work for folders of ~ 1000 messages at a time (and will preserve the dates, etc.), that sounds fine. (And I'm also glad to learn from Bill Cole about the formail shell option to produce the .mbox file directly; I'll play with the date stuff and see how close I can get with that too.) But I do hold out some hope that maybe we can still convince Benny to just hold his nose and provide an IMAP-folder-to-.mbox command in MM itself. Maybe this will happen if we all just keep politely asking for this -- especially if we intimate that otherwise we will be using Mail.app as a MM utility, and/or that we will be poking around in MM's local files despite the warnings? Benny wrote: Instead the (very similar) need for local messages comes up quite often. The best argument for that is privacy, but (some day) I would like to solve that problem in a different way (encryption). I also resonate with the privacy argument. And I'm not sure about others, but at least for me this isn't the primary driver of the local-archive request: even if MM had some great encryption option, I'd still want a local archive option just as much. Benny wrote: I'm afraid no matter how I implement it then I'll have reports about it failing to be imported in some other app and in the end I'll need options for every variant of the `.mbox` format. But I won't really know before it's implemented. It might not be that bad. It's also possible that the people who want this particular feature will be able to cope with different .mbox formats by themselves (or that people will be able to easily use other utilities such as Emailalchemy to do any further translation that might be necessary)? I worry instead that if you provide an IMAP-folder-to-local-.mbox export command after all, you'll just drown in a chorus of Thank you!s... Bill Cole wrote: As someone who has retained email for 20+ years including a substantial spam corpus (it's a professional focus) I share the desire for a local, integrated, purely private, and reliable mail archive. That seems like another great example. Benny, would you really just recommend that Bill keep 20 years of SPAM online? (I'm worried that the answer will just be an enthusiastic 'yes!', but that seems like an unacceptable option to me.) Benny wrote: 2. Setup a dummy IMAP account in MailMate which is always offline and then see if you can use some variant of what I suggest in [this ticket](https://freron.lighthouseapp.com/projects/58672/tickets/733). Has anyone made this work well? I haven't seen anyone on the list or in that ticket reply that this has worked for them. (In the ticket Benny notes that he hasn't actually tried it. And it sounds like Bill Cole tried this but didn't test it fully?) Michael Tsai wrote: Currently, MailMate sends EagleFiler .eml files: http://c-command.com/eaglefiler/help/importing-mail-from-mai However, you can merge them into mbox files for greater efficiency if you want: http://c-command.com/eaglefiler/help/merge-mailboxes-message Do you have any thoughts about whether this would work for bulk archiving -- e.g. if I wanted to take the entire contents of a ~ 1000-message IMAP folder, send them all in one step to EagleFiler from MM, and then convert the results (and only those results) into a single .mbox file? (And does this option successfully preserve all of the dates, unlike the simple version of Bill Cole's formail shell command?) If so, I'm tempted to just use this (especially since this would mean never having to open Mail.app). (And thanks for the quick reply, Michael; I will also eagerly be buying an EagleFiler license shortly!) Bill Cole wrote: I'm surprised that no one in this thread has yet mentioned the simple ability to select messages in a MM message list and drag them to a Finder window: a very fast way to create a file-per-message offline local archive. Same question: would this work well (and in a date-preserving way, etc.) for ~ 1000 messages at a time, with the results then imported into EagleFiler and transmuted into a single .mbox? But it seems like my best bet really might be to just skip the export step (via the EF bundle or dragging-to-finder or creating a zombie/offline IMAP account) altogether, and just periodically steal the archive
Re: [MlMt] Local email archiving status/options?
On Aug 25, 2015, at 6:33 AM, Brian Scholl bjsch...@gmail.com wrote: When others on the list have talked about using EagleFiler to archive their mail, for example, how do you get the messages from MM into EagleFiler? Currently, MailMate sends EagleFiler .eml files: http://c-command.com/eaglefiler/help/importing-mail-from-mai However, you can merge them into mbox files for greater efficiency if you want: http://c-command.com/eaglefiler/help/merge-mailboxes-message 5. LOCAL ARCHIVING TO MBOX FILES VIA A DIFFERENT EMAIL CLIENT? Back in January on this list, Scott McIntyre mentioned in passing that it is possible to use MM for everyday email, but then occasionally run Mail.app to access the same IMAP account, use that to save/translate the folder to a local mbox file, and then import that mbox file into DevonThink or EagleFiler for long term access. This should be easy. You can just set up Apple Mail to use the same server info as MailMate, and it will stay in sync via IMAP. Then just select the messages you want to import and press EagleFiler's capture key: http://c-command.com/eaglefiler/help/importing-mail-from-app No need to find the files in Mail or use its mbox export, which is buggy. --Michael -- Michael Tsai C-Command Software ___ mailmate mailing list mailmate@lists.freron.com http://lists.freron.com/listinfo/mailmate
