1 |
On Monday 27 May 2013 15:28:24 Alan McKinnon wrote: |
2 |
> I have travelled exactly the same path as you, and feel all your pain. |
3 |
> |
4 |
> At first I used claws but after a few months it got unbearably slow when |
5 |
> dealing with calendars and invites, so I switched to Thunderbird. It |
6 |
> works well enough for me. |
7 |
|
8 |
Yes, I've given Claws a go for a couple of months. I seem to recall I had set |
9 |
up a different MAIL directory for it. I can't recall what I didn't like, but |
10 |
there was too much not going the way I wanted it - keyboard shortcuts, |
11 |
attachments, gpg/SMIME and its integration with the address book, etc. After |
12 |
some time of the client getting in the way of me managing my email, I decided |
13 |
to return to kmail with some relief. |
14 |
|
15 |
My wife was using T'bird back then and would you believe it, I convinced her |
16 |
that Kmail was better. So she switched! Ha, ha, ha! I tried T'bird a few |
17 |
times and it also didn't work as I wanted it. In particular I recall message |
18 |
bodies being chopped off half way when encrypted. Not sure if this was an |
19 |
enigmail bug, but was a no go for me. I haven't tried it more recently. |
20 |
|
21 |
|
22 |
> Let's first establish your needs, I see a few points that don't make |
23 |
> much real-world sense. |
24 |
> |
25 |
> You retrieve your mail from Gmail, and then selectively delete stuff |
26 |
> from Google's servers. Why are you doing that? Gmail is built to archive |
27 |
> everything forever and most people's mail quickly gets to be a lot of |
28 |
> mail. I can understand leaving all of it there in an archive, or |
29 |
> deleting all of it, depending on how you like to do your backups, but I |
30 |
> don't understand the selective delete part. Looks like a lot of manual |
31 |
> work on your part. |
32 |
|
33 |
I use Google's Gmail servers as my BIG mail back up. The rarely performed |
34 |
selective delete is for messages that are rubbish (e.g. SPAM), messages that |
35 |
contain private info and in the long run I don't trust Google with them, |
36 |
messages that I know I won't read ever again and are just occupying space. |
37 |
|
38 |
I know what you are thinking - I don't pay for the space, so why not leave |
39 |
them there? Other than the odd private message which I would delete anyway, I |
40 |
am also thinking of the bandwidth and download time, when I wish to start |
41 |
afresh with a new machine/client. |
42 |
|
43 |
I know that I could just copy over the messages from my hard drive to the new |
44 |
PC/fs, but what if I have a catastrophic failure, or theft of my |
45 |
laptop/desktop and local back ups? Having the option to download the lot from |
46 |
Google's servers is a benefit for me. |
47 |
|
48 |
|
49 |
> I wouldn't try using mail clients to directly access the same local |
50 |
> mailbox structure. No two clients work the same way, they all index |
51 |
> mails differently, other subtle differences exist and there's always |
52 |
> locking issues. Mutt and kmail might not respect each other's turf... |
53 |
|
54 |
Yes, you are right here. I think there are warnings out in the interworks to |
55 |
*not* access Kmail's maildir simultaneously with another mail client. This |
56 |
can corrupt Kmail's .index files. The trick is to delete the relevant index |
57 |
file, so that kmail can recreate it, but I am aware of this problem and would |
58 |
not be accessing the maildir at the same time with different clients. |
59 |
|
60 |
|
61 |
> I recommend a man in the middle - a local IMAP serve of your choice that |
62 |
> works fast for you and stores mail acceptably for you. Fetch your mail |
63 |
> using fetchmail or one of it's friends, use procmail to filter it and |
64 |
> feed it into your IMAP server, and connect to IMAP locally using any GUI |
65 |
> mail client you choose. This gives you a standard interface (IMAP) |
66 |
> instead of a weird interface (disk files store wherever however) and all |
67 |
> locking issues just go away. |
68 |
> |
69 |
> The above is what I did (and delete everything off Google's servers so I |
70 |
> do my own backups), and it makes most of the rest of your post redundant |
71 |
> and no longer apply. |
72 |
|
73 |
Ahh! Not really. ;-) |
74 |
|
75 |
I recall you or some other Gentoo user in this list advocating setting up |
76 |
dovecot or some such to locally collect and store messages. This aligns with |
77 |
the one task per tool approach that mutt's design philosophy fulfils as a |
78 |
simple MUA. It has its advantages, but also has its disadvantages. It |
79 |
requires me to do back ups, instead of relying on Google. It requires me to |
80 |
run a separate server (if I were to run this on my LAN, as opposed to my |
81 |
lap/desktop) and pay for it, instead of Google's 'free' infrastructure and |
82 |
energy bill. One more application to configure and bother myself with, on the |
83 |
unexpected occasion when configuration files need editing in a rush because |
84 |
things no longer work since the last update. |
85 |
|
86 |
More critically, whether I run a local MRA/MTA or not, I will *still* need |
87 |
another mail client irrespective of where my messages are stored. This is why |
88 |
I kindly ask for some person who's more experienced on configuring mutt than |
89 |
I, to give me a hand setting it up. :-) |
90 |
|
91 |
If this is too much off topic, feel free to reply off list. |
92 |
|
93 |
-- |
94 |
Regards, |
95 |
Mick |