[MlMt] Local email archiving status/options?

Muster Hans muster at sture.ch
Fri Aug 28 04:55:35 EDT 2015


On 27 Aug 2015, at 22:27, Michael Tsai wrote:

> On Aug 27, 2015, at 3:03 PM, Muster Hans <muster at 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 <eaglefiler at 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=DefaultMessageEncoding&v=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 
> <eaglefiler at 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.


More information about the mailmate mailing list