[gentoo-user] Email clients

[Peter Humphrey]

Hello list,

I've been a loyal user of KMail for many years. (Loyal? Masochistic might be a
better word.) It suits me exactly - or it would if it were reliable. It isn't,
though, which drives me to consider alternatives.

Claws mail is often mentioned hereabouts, and I'd like to try it, but first I'd
need to export KMail's 20-odd-year maildir history to mbox format. Is it
enough to run KMail's Import/Export Data tool to do this? It should be, on the
face of it, but I'm suspicious (consider me paranoid if you like).

[Jack]

Post by Peter Humphrey
Hello list,
I've been a loyal user of KMail for many years. (Loyal? Masochistic might be a
better word.) It suits me exactly - or it would if it were reliable. It isn't,
though, which drives me to consider alternatives.
Claws mail is often mentioned hereabouts, and I'd like to try it, but first I'd
need to export KMail's 20-odd-year maildir history to mbox format. Is it
enough to run KMail's Import/Export Data tool to do this? It should be, on the
face of it, but I'm suspicious (consider me paranoid if you like).

I've been a happy user of Balsa for many years. It reads maildir as
is, no conversion necessary. Can also use mbox and other formats, and
does IMAP as well as POP3.

Jack

[Bryan Gardiner]

On Sat, 29 Jul 2023 01:29:59 +0100

Post by Peter Humphrey
Hello list,
I've been a loyal user of KMail for many years. (Loyal? Masochistic
might be a better word.) It suits me exactly - or it would if it were
reliable. It isn't, though, which drives me to consider alternatives.
Claws mail is often mentioned hereabouts, and I'd like to try it, but
first I'd need to export KMail's 20-odd-year maildir history to mbox
format. Is it enough to run KMail's Import/Export Data tool to do
this? It should be, on the face of it, but I'm suspicious (consider
me paranoid if you like).

User of Claws with a local maildir here. One mail per file always
felt safer to me. If you do want to keep using maildir,
net-mail/dovecot provides IMAP access to ~/.maildir out of the box,
and I've found this combination to be reliable.

Since it's "just" local IMAP, moving data in and out can be done with
most mail clients. Plus it means you're not tied to a single mail
client going forward.

I do miss KMail's breadth of features though. Never tried it's
migration tools, sorry.

Cheers,
Bryan

[Wols Lists]

Post by Bryan Gardiner
User of Claws with a local maildir here. One mail per file always
felt safer to me. If you do want to keep using maildir,
net-mail/dovecot provides IMAP access to ~/.maildir out of the box,
and I've found this combination to be reliable.

Just a tip which bit me when I first installed dovecot ...

The master config file actually chain-loads a local config file, make
sure you use it. I edited the master file directly, so of course the
first update overwrote and trashed it ...

Cheers,
Wol

[Arsen Arsenović]

Post by Wols Lists

Post by Bryan Gardiner
User of Claws with a local maildir here. One mail per file always
felt safer to me. If you do want to keep using maildir,
net-mail/dovecot provides IMAP access to ~/.maildir out of the box,
and I've found this combination to be reliable.

Just a tip which bit me when I first installed dovecot ...
The master config file actually chain-loads a local config file, make sure you
use it. I edited the master file directly, so of course the first update
overwrote and trashed it ...

That should not happen. Where's the master config file? Is it under a
directory masked by CONFIG_PROTECT?

~$ portageq envvar CONFIG_PROTECT
/etc /usr/share/config

... on my machine (re-run on yours to check)

Post by Wols Lists
Cheers,
Wol

[Wols Lists]

Post by Arsen Arsenović

Post by Wols Lists

Post by Bryan Gardiner
User of Claws with a local maildir here. One mail per file always
felt safer to me. If you do want to keep using maildir,
net-mail/dovecot provides IMAP access to ~/.maildir out of the box,
and I've found this combination to be reliable.

Just a tip which bit me when I first installed dovecot ...
The master config file actually chain-loads a local config file, make sure you
use it. I edited the master file directly, so of course the first update
overwrote and trashed it ...

That should not happen. Where's the master config file? Is it under a
directory masked by CONFIG_PROTECT?

And then the dovecot maintainers update things, update the config file,
and it breaks for all users because the config version no longer matches
the program version ...

The master config file is in the obvious place -
/etc/dovecot/dovecot.conf. Just like postfix breaks exactly the same way
- /etc/postfix/main.cf.

Imho dovecot has got this (almost) exactly right. Just like systemd. You
have your master file that is updated by the distro, and you have your
local file that is updated by the sys admin.

dovecot.conf points to a file local.conf, which does not error if it
doesn't exist, but over-rides dovecot.conf if it does. The proper way to
do it!

Unlike postfix - where I can't find a place to split my local config
away from the default config - so every time postfix is updated I have
to make sure it doesn't try to update main.cf !!!

Cheers,
Wol

[Arsen Arsenović]

Post by Arsen Arsenović

Post by Wols Lists

Post by Bryan Gardiner
User of Claws with a local maildir here. One mail per file always
felt safer to me. If you do want to keep using maildir,
net-mail/dovecot provides IMAP access to ~/.maildir out of the box,
and I've found this combination to be reliable.

Just a tip which bit me when I first installed dovecot ...
The master config file actually chain-loads a local config file, make sure you
use it. I edited the master file directly, so of course the first update
overwrote and trashed it ...

That should not happen. Where's the master config file? Is it under a
directory masked by CONFIG_PROTECT?

And then the dovecot maintainers update things, update the config file, and it
breaks for all users because the config version no longer matches the program
version ...

I don't recall Dovecot configs being version sensitive.

The master config file is in the obvious place -
/etc/dovecot/dovecot.conf. Just like postfix breaks exactly the same way -
/etc/postfix/main.cf.

Then that should not have been overwritten.

Imho dovecot has got this (almost) exactly right. Just like systemd. You have
your master file that is updated by the distro, and you have your local file
that is updated by the sys admin.
dovecot.conf points to a file local.conf, which does not error if it doesn't
exist, but over-rides dovecot.conf if it does. The proper way to do it!

I agree, but this is still suspicious. CONFIG_PROTECT should've
prevented that, and offered dispatch-conf instead.

Unlike postfix - where I can't find a place to split my local config away from
the default config - so every time postfix is updated I have to make sure it
doesn't try to update main.cf !!!

Again, it shouldn't be able to do that. Please check CONFIG_PROTECT
using: portageq envvar CONFIG_PROTECT

It should, normally, contain /etc, set by profiles/base/make.defaults.

Have a lovely day.

[Wols Lists]

Post by Arsen Arsenović
Again, it shouldn't be able to do that. Please check CONFIG_PROTECT
using: portageq envvar CONFIG_PROTECT
It should, normally, contain /etc, set by profiles/base/make.defaults.

And here is the root of the mis-understanding between us. And also why
Dovecot does it right, and Postfix does it wrong.

WHY SHOULD I HAVE TO USE DISPATCH-CONF? (Or in my case, etc-update.)

The point is I don't (have to) care whether dovecot.conf is updated or
not. I never change it from the distro defaults, so it never offers me
etc-update, and it never does any damage.

But I DO have to care about postfix/main.cf. This makes the fundamental
blunder of mixing distro defaults and local config in the SAME FILE. So
yes it does offer me etc-update. But if I MISS THAT, I've just trashed
my local config and have to rebuild it.

At the end of the day, if you can't keep distro and local config
separate, that's a fault of the upstream application. etc-update and
dispatch-conf are gentoo's way of working round the breakage. IFF you
use dovecot/local.conf, it's a sign of good design by the upstream
application, and etc-update or dispatch-conf are completely UNNECESSARY.

Cheers,
Wol

[Arsen Arsenović]

Post by Arsen Arsenović
Again, it shouldn't be able to do that. Please check CONFIG_PROTECT
using: portageq envvar CONFIG_PROTECT
It should, normally, contain /etc, set by profiles/base/make.defaults.

And here is the root of the mis-understanding between us. And also why Dovecot
does it right, and Postfix does it wrong.
WHY SHOULD I HAVE TO USE DISPATCH-CONF? (Or in my case, etc-update.)
The point is I don't (have to) care whether dovecot.conf is updated or not. I
never change it from the distro defaults, so it never offers me etc-update, and
it never does any damage.
But I DO have to care about postfix/main.cf. This makes the fundamental blunder
of mixing distro defaults and local config in the SAME FILE. So yes it does
offer me etc-update. But if I MISS THAT, I've just trashed my local config and
have to rebuild it.

If portage trashes the local file, something went wrong. That is the
only thing that I'm trying to get to the bottom of in this thread.
Application design is irrelevant to that.

You say that the opportunity to etc-update is offered? If so, portage
worked as it should and I'm satisfied, but I'm still confused about how
the contents got trashed.

At the end of the day, if you can't keep distro and local config separate,
that's a fault of the upstream application. etc-update and dispatch-conf are
gentoo's way of working round the breakage. IFF you use dovecot/local.conf,
it's a sign of good design by the upstream application, and etc-update or
dispatch-conf are completely UNNECESSARY.
Cheers,
Wol

[Wols Lists]

Post by Arsen Arsenović

But I DO have to care about postfix/main.cf. This makes the fundamental blunder
of mixing distro defaults and local config in the SAME FILE. So yes it does
offer me etc-update. But if I MISS THAT, I've just trashed my local config and
have to rebuild it.

If portage trashes the local file, something went wrong. That is the
only thing that I'm trying to get to the bottom of in this thread.
Application design is irrelevant to that.
You say that the opportunity to etc-update is offered? If so, portage
worked as it should and I'm satisfied, but I'm still confused about how
the contents got trashed.

Because - with dovecot - I initially made the mistake of editing the
global file. etc-update over-wrote it.

With postfix, I cannot see any way of NOT editing the global file.

If you go back to what started all this, it was me advising the OP to
make sure he edited the dovecot local file, not the global one.

And yes, portage is working as it should, but it is working to mitigate
breakage in the upstream application, namely postfix. Stuff it should
not need to do.

Cheers,
Wol

[Nuno Silva]

Post by Wols Lists

Post by Arsen Arsenović
Again, it shouldn't be able to do that. Please check CONFIG_PROTECT
using: portageq envvar CONFIG_PROTECT
It should, normally, contain /etc, set by profiles/base/make.defaults.

And here is the root of the mis-understanding between us. And also why
Dovecot does it right, and Postfix does it wrong.
WHY SHOULD I HAVE TO USE DISPATCH-CONF? (Or in my case, etc-update.)
The point is I don't (have to) care whether dovecot.conf is updated or
not. I never change it from the distro defaults, so it never offers me
etc-update, and it never does any damage.
But I DO have to care about postfix/main.cf. This makes the
fundamental blunder of mixing distro defaults and local config in the
SAME FILE. So yes it does offer me etc-update. But if I MISS THAT,
I've just trashed my local config and have to rebuild it.
At the end of the day, if you can't keep distro and local config
separate, that's a fault of the upstream application. etc-update and
dispatch-conf are gentoo's way of working round the breakage. IFF you
use dovecot/local.conf, it's a sign of good design by the upstream
application, and etc-update or dispatch-conf are completely
UNNECESSARY.
Cheers,
Wol

If you have a single file both with defaults (either as settings or
commented out) and your changes, you get to see when defaults change,
and it might be easier to notice, handle and adapt if some change
requires adjusting the modified settings.

I'd say having separate files also makes it possible to miss
configuration changes.

[Philip Webb]

Post by Peter Humphrey
I've been a loyal user of KMail for many years.
Claws mail is often mentioned hereabouts and I'd like to try it,
but first I'd need to export KMail's 20-odd-year maildir history
to mbox format.

I recommend a look at Mutt, which I've used very happily since c 1998 ,
well before Gentoo existed. I've also always used Mbox, not Maildir.
Powerful, configurable, but also simple : the UNIX approach.

[Frank Steinmetzger]

Post by Philip Webb

Post by Peter Humphrey
I've been a loyal user of KMail for many years.
Claws mail is often mentioned hereabouts and I'd like to try it,
but first I'd need to export KMail's 20-odd-year maildir history
to mbox format.

I recommend a look at Mutt, which I've used very happily since c 1998 ,
well before Gentoo existed. I've also always used Mbox, not Maildir.
Powerful, configurable, but also simple : the UNIX approach.

When I had kmail issues back in the day of early akonadi times (remember
Alan’s thread about data loss from then?), I tried out mutt and I’ve been
using it ever since. I configured it to my liking re. list layout, sidebar,
shortcuts, editing and so on.

I still use KMail these days, quite often too. But it has a few drawbacks
and annoying little bugs that I encounter regularly, which is one reason for
staying with mutt. Another is that mutt is much much faster when dealing
with big directories such as lists. Still, there is no better graphical
alternative in KDE land. Thunderbird & Co don’t fit in optically, Trojita is
too limited.

[Peter Humphrey]

Post by Frank Steinmetzger
When I had kmail issues back in the day of early akonadi times (remember
Alan’s thread about data loss from then?), I tried out mutt and I’ve been
using it ever since. I configured it to my liking re. list layout, sidebar,
shortcuts, editing and so on.

I haven't used Mutt in this century. I assume it's still similar in
appearance.

Post by Frank Steinmetzger
I still use KMail these days, quite often too. But it has a few drawbacks
and annoying little bugs that I encounter regularly, which is one reason for
staying with mutt. Another is that mutt is much much faster when dealing
with big directories such as lists. Still, there is no better graphical
alternative in KDE land. Thunderbird & Co don’t fit in optically, Trojita
is too limited.

Agreed. A glance at Thunderbird was enough. Never heard of Trojita.

Thanks all for the advice.

[Neil Bothwick]

Post by Peter Humphrey
Claws mail is often mentioned hereabouts, and I'd like to try it, but
first I'd need to export KMail's 20-odd-year maildir history to mbox
format. Is it enough to run KMail's Import/Export Data tool to do this?
It should be, on the face of it, but I'm suspicious (consider me
paranoid if you like).

Claws works with maildir. However, I'd also recommend setting up Dovecot
locally, then you can try as many mail clients as you want without having
to worry about where the mails are sotred or in what format.

[Peter Humphrey]

Post by Neil Bothwick

Post by Peter Humphrey
Claws mail is often mentioned hereabouts, and I'd like to try it, but
first I'd need to export KMail's 20-odd-year maildir history to mbox
format. Is it enough to run KMail's Import/Export Data tool to do this?
It should be, on the face of it, but I'm suspicious (consider me
paranoid if you like).

Claws works with maildir. However, I'd also recommend setting up Dovecot
locally, then you can try as many mail clients as you want without having
to worry about where the mails are sotred or in what format.

Hm. I already have Dovecot on my LAN server, because KMail is horribly buggy
with POP3, which is what my ISP offers. So fetchmail -> postfix -> dovecot
became necessary before I could use IMAP4 in KMail.

All incoming emails are transferred to my workstation because I like to have
everything in one place and one backup.

Maybe I'll stick with KMail a bit longer...

[Wols Lists]

Post by Peter Humphrey
Hm. I already have Dovecot on my LAN server, because KMail is horribly buggy
with POP3, which is what my ISP offers. So fetchmail -> postfix -> dovecot
became necessary before I could use IMAP4 in KMail.
All incoming emails are transferred to my workstation because I like to have
everything in one place and one backup.
Maybe I'll stick with KMail a bit longer...

Well then, install Claws and try it - just point it at Dovecot. Okay, I
use Thunderbird, but there's no reason I have to - I run about 4
different instances of TB, all pointing at my Dovecot server, and all
mail is visible on all my computers - the server/workstation, my old
laptop, my new laptop, my wife's laptop when I borrow it, ...

Cheers,
Wol

[Neil Bothwick]

Post by Wols Lists

Post by Peter Humphrey
Hm. I already have Dovecot on my LAN server, because KMail is
horribly buggy with POP3, which is what my ISP offers. So fetchmail
-> postfix -> dovecot became necessary before I could use IMAP4 in
KMail.
All incoming emails are transferred to my workstation because I like
to have everything in one place and one backup.
Maybe I'll stick with KMail a bit longer...

Well then, install Claws and try it - just point it at Dovecot. Okay, I
use Thunderbird, but there's no reason I have to - I run about 4
different instances of TB, all pointing at my Dovecot server, and all
mail is visible on all my computers - the server/workstation, my old
laptop, my new laptop, my wife's laptop when I borrow it, ...

Similarly, I use Claws 99% of the time, but occasionally run Thunderbird.
Neither program cares that I have also used the other to read my mail.

[Peter Humphrey]

... I use Claws 99% of the time, but occasionally run Thunderbird. Neither
program cares that I have also used the other to read my mail.

Ah, but you're using IMAP4 and leaving your emails on the server. I don't want
to do that.

[Neil Bothwick]

Post by Peter Humphrey

... I use Claws 99% of the time, but occasionally run Thunderbird.
Neither program cares that I have also used the other to read my mail.

Ah, but you're using IMAP4 and leaving your emails on the server. I
don't want to do that.

But you're running the IMAP server locally, so what difference does it
make?

[Wols Lists]

Post by Neil Bothwick

Post by Peter Humphrey

... I use Claws 99% of the time, but occasionally run Thunderbird.
Neither program cares that I have also used the other to read my mail.

Ah, but you're using IMAP4 and leaving your emails on the server. I
don't want to do that.

But you're running the IMAP server locally, so what difference does it
make?

My server IS my workstation. And if *you* don't want to leave your mail
"centrally", why are you running a dovecot server?

Cheers,
Wol

[Peter Humphrey]

Post by Wols Lists

Post by Neil Bothwick

Post by Peter Humphrey

... I use Claws 99% of the time, but occasionally run Thunderbird.
Neither program cares that I have also used the other to read my mail.

Ah, but you're using IMAP4 and leaving your emails on the server. I
don't want to do that.

But you're running the IMAP server locally, so what difference does it
make?

It's just the way things have 'just growed'. I could start again with the
server keeping the mails itself, but it's a good deal of work.

Post by Wols Lists
My server IS my workstation. And if *you* don't want to leave your mail
"centrally", why are you running a dovecot server?

Because KMail is horribly buggy with POP3 and my ISP doesn't offer IMAP4.

[Neil Bothwick]

Post by Peter Humphrey

Post by Neil Bothwick
But you're running the IMAP server locally, so what difference does
it make?

It's just the way things have 'just growed'. I could start again with
the server keeping the mails itself, but it's a good deal of work.

Not really. Once you have set up the server and a folder for it in KMail,
you just move your mails from the local folder to the IMAP one.

[Peter Humphrey]

I already have it set up, so I hope I'd only have to deselect "Download all
messages for offline use" and then drag the locally stored emails to the IMAP
Account, which is shown at the top of the folder list, attached. Does that
create a copy of the local directory structure?

Hah! I just tried the folder-move function in KMail, and it crashed. 79 emails
and 2.2MB.

[Peter Humphrey]

Post by Peter Humphrey

I already have it set up, so I hope I'd only have to deselect "Download all
messages for offline use" and then drag the locally stored emails to the
IMAP Account, which is shown at the top of the folder list, attached.
Does that create a copy of the local directory structure?

Hah! I just tried the folder-move function in KMail, and it crashed. 79
emails and 2.2MB.

It wasn't too hard after all, mostly. I still have sent-mail, outbox,
wastebin, drafts and templates locally.

I thought I should be able to specify where outgoing mail should be put, but I
can't find it now.

[Michael]

Post by Peter Humphrey
I thought I should be able to specify where outgoing mail should be
put, but I can't find it now.

That's a setting in the mail client.

Kmail Settings > Accounts > Identities > Advanced > Sent-mail folder.

Also set the Outgoing Account at the same time to configure your SMTP.

[Peter Humphrey]

Post by Michael

Post by Peter Humphrey
I thought I should be able to specify where outgoing mail should be
put, but I can't find it now.

That's a setting in the mail client.

Kmail Settings > Accounts > Identities > Advanced > Sent-mail folder.

Ah. I didn't expect to find it under Identities. Odd.

Post by Michael
Also set the Outgoing Account at the same time to configure your SMTP.

Of course. Long since done.

[Michael]

Post by Peter Humphrey

Post by Michael

Post by Peter Humphrey
I thought I should be able to specify where outgoing mail should be
put, but I can't find it now.

That's a setting in the mail client.

Kmail Settings > Accounts > Identities > Advanced > Sent-mail folder.

Ah. I didn't expect to find it under Identities. Odd.

The idea being to separate the SMTP server and corresponding authentication
credentials you may send messages with, from the Sent Folder(s) each sent
messages is saved in, while using different 'From' email account identities.

[Peter Humphrey]

Post by Michael
The idea being to separate the SMTP server and corresponding authentication
credentials you may send messages with, from the Sent Folder(s) each sent
messages is saved in, while using different 'From' email account identities.

It seems I have a non-standard use of identities: I use them to include
different personal details in my signature, not for separate personas in
different cases.

[Neil Bothwick]

Post by Peter Humphrey
I thought I should be able to specify where outgoing mail should be
put, but I can't find it now.

That's a setting in the mail client.

[Michael]

Post by Peter Humphrey

I already have it set up, so I hope I'd only have to deselect "Download all
messages for offline use" and then drag the locally stored emails to the
IMAP Account, which is shown at the top of the folder list, attached.
Does that create a copy of the local directory structure?

Hah! I just tried the folder-move function in KMail, and it crashed. 79
emails and 2.2MB.

I have used Kmail to download large-ish IMAP folders (4000+ messages and
~800MB) to local folders, then upload them to different remote IMAP account/
folder.

It has worked reliably here and ought to work in your case too, if:

- Your Internet connectivity is stable and the bandwidth is > than dial up, or
you work locally with dovecot.

- You create the local/remote Kmail folders first and then copy messages over
in small numbers. About 50-100 at a time should do it, depending on size of
attachments.

- You remain patient until the messages have downloaded, but then you really
remain patient until akonadi finishes indexing them. This may take longer
than you wish.[1]

- Do not start with another folder, until the current folder migration has
completed successfully and you can verify the content of at least a sample of
messages has landed where you expect it to be.

[1] Sometimes synchronising a large number of messages/folders will appear to
be stuck, because Kmail won't display it. A workaround I use is to close
Kmail and run in a terminal:

akonadictl fsck
akonadictl vacuum

waiting for each command to finish, before I restart Kmail. This is not a
regular occurrence, but when Kmail misbehaves the above forces a sync so the
next batch of emails can be copied over.

HTH.

[Peter Humphrey]

Post by Michael

Post by Peter Humphrey

I already have it set up, so I hope I'd only have to deselect "Download all
messages for offline use" and then drag the locally stored emails to the
IMAP Account, which is shown at the top of the folder list, attached.
Does that create a copy of the local directory structure?

Hah! I just tried the folder-move function in KMail, and it crashed. 79
emails and 2.2MB.

I have used Kmail to download large-ish IMAP folders (4000+ messages and
~800MB) to local folders, then upload them to different remote IMAP account/
folder.

It works here too now. I don't know what caused that one blip.

[Neil Bothwick]

What should I do about backups of the server?

Don't bother, hard disks are dead reliable these days ;-)

[Wols Lists]

Post by Peter Humphrey

Post by Wols Lists

Post by Neil Bothwick

Post by Peter Humphrey

... I use Claws 99% of the time, but occasionally run Thunderbird.
Neither program cares that I have also used the other to read my mail.

Ah, but you're using IMAP4 and leaving your emails on the server. I
don't want to do that.

But you're running the IMAP server locally, so what difference does it
make?

It's just the way things have 'just growed'. I could start again with the
server keeping the mails itself, but it's a good deal of work.

Post by Wols Lists
My server IS my workstation. And if *you* don't want to leave your mail
"centrally", why are you running a dovecot server?

Because KMail is horribly buggy with POP3 and my ISP doesn't offer IMAP4.

I'm trying to get my head round your setup then.

My setup is simple. I couldn't get postfix/fetchmail to behave, so my
workstation/server runs dovecot.

Thunderbird (on my server) has an account pointing at my ISP, that
retrieves all my mail and moves it into dovecot. Am I right you've got
postfix/fetchmail working correctly? All you need to do is make it chuck
it into dovecot on your server (or not even that).

But the point is, if you have a working instance of dovecot, and you are
using kmail/imap4 to read your emails FROM DOVECOT, just point claws at
dovecot as well.

Or are you using kmail/pop3 to pull your emails from dovecot into your
local kmail instance?

The big question that needs answering is "Are you storing your emails in
dovecot, or in kmail?"

Cheers,
Wol

[Peter Humphrey]

Post by Wols Lists
The big question that needs answering is "Are you storing your emails in
dovecot, or in kmail?"

In KMail.

My server has fetchmail -> postfix -> dovecot. Fetchmail collects POP3 emails
from my ISP and forwards it to postfix, and dovecot serves IMAP4 to my
workstation.

My backup method is simple: I archive KMail's emails daily to a local disk,
then shut the system down on a Sunday to back up the entire system to an
external USB-3 disk.

The server is taken down on a Saturday for complete system backup, to another
USB-3 disk.

[Wols Lists]

Post by Peter Humphrey

Post by Wols Lists
The big question that needs answering is "Are you storing your emails in
dovecot, or in kmail?"

In KMail.
My server has fetchmail -> postfix -> dovecot. Fetchmail collects POP3 emails
from my ISP and forwards it to postfix, and dovecot serves IMAP4 to my
workstation.

So if Dovecot is serving IMAP4 to your workstation, the emails should be
in dovecot, and cached on your workstation. For my setup, they're stored
in dovecot, and cached in thunderbird ...

Post by Peter Humphrey
My backup method is simple: I archive KMail's emails daily to a local disk,
then shut the system down on a Sunday to back up the entire system to an
external USB-3 disk.

If kmail is caching them, chances are they're stashed away in the .kmail
directory or wherever, in some standard format, and you can just back
that up.

Post by Peter Humphrey
The server is taken down on a Saturday for complete system backup, to another
USB-3 disk.

Perfect, they're now backed up all over the place :-)

Cheers,
Wol

[Peter Humphrey]

Post by Wols Lists
So if Dovecot is serving IMAP4 to your workstation, the emails should be
in dovecot, and cached on your workstation. For my setup, they're stored
in dovecot, and cached in thunderbird ...

Almost. KMail has a 'Download messages for offline use' option, which I've had
set until now.

Post by Wols Lists

Post by Peter Humphrey
My backup method is simple: I archive KMail's emails daily to a local disk,
then shut the system down on a Sunday to back up the entire system to an
external USB-3 disk.

If kmail is caching them, chances are they're stashed away in the .kmail
directory or wherever, in some standard format, and you can just back
that up.

Yes, I'm doing that. It now takes longer to make the backup because the emails
have to be fetched from the server.

Post by Wols Lists

Post by Peter Humphrey
The server is taken down on a Saturday for complete system backup, to
another USB-3 disk.

Perfect, they're now backed up all over the place :-)

Quite so. :-)

[Michael]

Post by Peter Humphrey
Hello list,
I've been a loyal user of KMail for many years. (Loyal? Masochistic might be
a better word.) It suits me exactly - or it would if it were reliable. It
isn't, though, which drives me to consider alternatives.

I've been using Kmail since the good ol' KDE3 days. Back then it worked at
least as good if not better than any other mail client I had tried. With the
move to KDE4, Kmail became the worse mail client I have ever used. I mean,
*catastrophically* worse! Both for the messages involved and for my nerves.
Initially I blamed sqlite, which I was using as its back end for a season, but
things were not much better with mysql. At some point I tried postgresql,
which was more robust. Over the years the code matured. For some years now,
Kmail is quite stable. There are still a couple of glitches with its GUI,
e.g. the columns width has a mind of its own and recently its Korganizer
sister application notifications cannot be snoozed for a short period of time,
but overall it works without any drama.

Post by Peter Humphrey
Claws mail is often mentioned hereabouts, and I'd like to try it, but first
I'd need to export KMail's 20-odd-year maildir history to mbox format.

Among many other email applications, I gave Claws a spin. A couple of months
later I abandoned it, because I ended up spending more time trying to bend it
out of shape to behave like Kmail (from keybindings, to layout, to
attachments, etc.) than I was spending using it. Soon, my attempts to change
its behaviour hit a wall of non-adjustable hardcoded features. I don't blame
Claws for this, rather my brain which had been accustomed to work with Kmail.

The mbox single file format is something I tried to move away from since the
90s, because as it grows in size it becomes more prone to corruption. Losing
one message may be tolerable, but losing the lot less so. Sure, backups exist
for a reason, but why accept architectural weaknesses if there is the more
modern alternative of maildir?

Post by Peter Humphrey
Is
it enough to run KMail's Import/Export Data tool to do this? It should be,
on the face of it, but I'm suspicious (consider me paranoid if you like).

I'll echo the recommendation for dovecot, plus backup(s). If things go
sideways during your experiment, you can rinse and repeat. This is just good
practice.

That said, I have used the Kmail Import/Export data tool in the past to move
messages between Kmail and Thunderbird. It worked, but can't recall the
details.

[Matt Connell]

Post by Peter Humphrey
I've been a loyal user of KMail for many years. (Loyal? Masochistic
might be a better word.) It suits me exactly - or it would if it were
reliable. It isn't, though, which drives me to consider alternatives.

To present an alternative that I haven't seen mentioned in the thread:
Evolution.  

- Fully featured (calendar, contacts, tasks, memos)
- Oauth2 support
- Exchange Web Services support
- sane defaults
- sqlite database storage (as opposed to Akonadi's mysql)
- active community mailing list.

[Peter Humphrey]

Post by Matt Connell

Post by Peter Humphrey
I've been a loyal user of KMail for many years. (Loyal? Masochistic
might be a better word.) It suits me exactly - or it would if it were
reliable. It isn't, though, which drives me to consider alternatives.

Evolution.
- Fully featured (calendar, contacts, tasks, memos)
- Oauth2 support
- Exchange Web Services support
- sane defaults
- sqlite database storage (as opposed to Akonadi's mysql)
- active community mailing list.

I'll have a look at it - thanks.

I see it's a gnome program and has 17 new dependencies (to this box).

[Matt Connell]

Post by Peter Humphrey
I see it's a gnome program and has 17 new dependencies (to this box).

Unfortunately one of them is webkit-gtk, which, if you don't have it
already, is a compilation lift.

Normally I would be in the chorus of "why do I need a whole entire web
engine for an email client" but I'm also in the group of people who
knows full well what the answer is.

[Alexe Stefan]

Post by Matt Connell
Normally I would be in the chorus of "why do I need a whole entire web
engine for an email client" but I'm also in the group of people who
knows full well what the answer is.

What is the answer?
Mutt doesn't need a web engine.

[Matt Connell]

Post by Alexe Stefan

Post by Matt Connell
Normally I would be in the chorus of "why do I need a whole entire web
engine for an email client" but I'm also in the group of people who
knows full well what the answer is.

What is the answer?
Mutt doesn't need a web engine.

For the reason that you just demonstrated for the class: HTML emails.

Now, your simple mail shows just fine in a plain text only mail client,
but in my world, and I'd wager most people's world, handling HTML
messages (which includes CSS for legibility) is a necessity to some
varying degree.

Don't get me wrong, I'm "team plaintext" all day every day but I'm not
going to make my life more difficult on principles. There are hills
worth dying on but this isn't mine.

[Kusoneko]

Post by Matt Connell

Post by Alexe Stefan

Post by Matt Connell
Normally I would be in the chorus of "why do I need a whole entire web
engine for an email client" but I'm also in the group of people who
knows full well what the answer is.

What is the answer?
Mutt doesn't need a web engine.

For the reason that you just demonstrated for the class: HTML emails.
Now, your simple mail shows just fine in a plain text only mail client,
but in my world, and I'd wager most people's world, handling HTML
messages (which includes CSS for legibility) is a necessity to some
varying degree.
Don't get me wrong, I'm "team plaintext" all day every day but I'm not
going to make my life more difficult on principles.  There are hills
worth dying on but this isn't mine.

Iirc, you can setup mutt to open html emails either in a web browser or with something like w3m. There's no need for a web engine in a mail client when you have a perfectly workable web engine in the browser. You can easily reply to html mail in plain text either way, and most html mail are marketing or newsletter emails from companies where replying isn't needed anyways.

[Grant Edwards]

Post by Kusoneko

Post by Matt Connell
Don't get me wrong, I'm "team plaintext" all day every day but I'm not
going to make my life more difficult on principles.  There are hills
worth dying on but this isn't mine.

Iirc, you can setup mutt to open html emails either in a web browser
or with something like w3m.

Wait -- those are web engines. I thought the argument was that mutt
didn't need a web engine. If that was the case, then you would have no
need to set up mutt to use them to display HTML email.

Post by Kusoneko
There's no need for a web engine in a mail client when you have a
perfectly workable web engine in the browser.

Composing HTML also e-mails requires a web-engine. Sure, you can do
that using emacs, markdown mode, a web browser for previewing, and so
on. It's a lot of work.

Post by Kusoneko
You can easily reply to html mail in plain text either way,

Some other MUAs handle plain text acceptably, some don't. After I saw
how badly Outlook displayed my plaintext e-mails, I tried using
markdown to auto-magically send mixed-mode text/html emails (see
muttdown). That worked OK, but was a hassle.

I eventually gave up and switched to Thunderbird.

Post by Kusoneko
and most html mail are marketing or newsletter emails from companies
where replying isn't needed anyways.

Most of the HTML mail that lands in my inbox is from friends, family
and colleagues.

--
Grant

[Kusoneko]

Post by Grant Edwards

Post by Kusoneko

Post by Matt Connell
Don't get me wrong, I'm "team plaintext" all day every day but I'm not
going to make my life more difficult on principles.  There are hills
worth dying on but this isn't mine.

Iirc, you can setup mutt to open html emails either in a web browser
or with something like w3m.

Wait -- those are web engines. I thought the argument was that mutt
didn't need a web engine. If that was the case, then you would have no
need to set up mutt to use them to display HTML email.

Why would you want a mail client to also be a web browser when you already have a web browser to do that job? I will never understand the mindset of trying to include web browsers into everything. Web browsers are massive pieces of software, including one in everything massively increases the compile time and resource usage of the software it's added into.

Post by Grant Edwards

Post by Kusoneko
There's no need for a web engine in a mail client when you have a
perfectly workable web engine in the browser.

Composing HTML also e-mails requires a web-engine. Sure, you can do
that using emacs, markdown mode, a web browser for previewing, and so
on. It's a lot of work.

I don't get the point of composing HTML emails. Let's be honest here, unless you're writing emails as part of a company with complicated messes of html signatures or marketing emails, the only difference between composing a plain text email and a html email for most people is unnoticeable. At most they might use a specific font, text color, font size and maybe include an image or 2 which will land in the attachments anyways. Displaying the text with those unnecessary stylistic changes that only really pleases the eye of the writer makes the whole thing pointless. You could just as easily strip all the HTML from the email and leave only the text and attachments and you'd get a much better experience on the receiving end.

Post by Grant Edwards

Post by Kusoneko
You can easily reply to html mail in plain text either way,

Some other MUAs handle plain text acceptably, some don't.  After I saw
how badly Outlook displayed my plaintext e-mails, I tried using
markdown to auto-magically send mixed-mode text/html emails (see
muttdown). That worked OK, but was a hassle.
I eventually gave up and switched to Thunderbird.

If a MUA can't handle plain text, that's technically not your problem but the MUA's dev's problem.

Post by Grant Edwards

Post by Kusoneko
and most html mail are marketing or newsletter emails from companies
where replying isn't needed anyways.

Most of the HTML mail that lands in my inbox is from friends, family
and colleagues.

Like I said earlier, for friends and family, most are likely plain text with extra steps, with perhaps a few attachments. The colleagues one is likely mostly the same except for a few exceptions and the signatures. They also usually get Google Suite or Office365 for their email stuff, which essentially means that for them specifically you can just go with the... ugh... webmail client they offer.

[Matt Connell]

Post by Kusoneko
Why would you want a mail client to also be a web browser when you already have a web browser to do that job? I will never understand the mindset of trying to include web browsers into everything. Web browsers are massive pieces of software, including one in everything massively increases the compile time and resource usage of the software it's added into.

This is why webkit-gtk exists as it does: so it can fulfill this role
as part of multiple packages. I'm not defending it, I'm just saying it
isn't completely nonsensical to have "browser as a library/module".

Post by Kusoneko

Post by Grant Edwards
Composing HTML also e-mails requires a web-engine. Sure, you can do
that using emacs, markdown mode, a web browser for previewing, and so
on. It's a lot of work.

I don't get the point of composing HTML emails. Let's be honest here, unless you're writing emails as part of a company with complicated messes of html signatures or marketing emails, the only difference between composing a plain text email and a html email for most people is unnoticeable.

Or your company forcibly converts emails to HTML so that it can apply a
signature, and you have no say in the matter. Like mine. So I write
HTML mails from the get-go so I can have a (better) chance to ensure
they are formatted correctly.

[David Rosenbaum]

David

Post by Kusoneko

Post by Grant Edwards

Post by Kusoneko

Post by Matt Connell
Don't get me wrong, I'm "team plaintext" all day every day but I'm not
going to make my life more difficult on principles. There are hills
worth dying on but this isn't mine.

Iirc, you can setup mutt to open html emails either in a web browser
or with something like w3m.

Wait -- those are web engines. I thought the argument was that mutt
didn't need a web engine. If that was the case, then you would have no
need to set up mutt to use them to display HTML email.

Why would you want a mail client to also be a web browser when you
already have a web browser to do that job?

I don't want a mail client that's also a web browser. I want a mail
client that renders HTML. That's only a small small of what a web
browser does. Most of what a web browser does these days is provide an
environment in which to run JavaScript.

Post by Kusoneko
I will never understand the mindset of trying to include web
browsers into everything. Web browsers are massive pieces of
software, including one in everything massively increases the
compile time and resource usage of the software it's added into.

That's because they do a lot more than just render HTML.

Post by Kusoneko

Post by Grant Edwards

Post by Kusoneko
There's no need for a web engine in a mail client when you have a
perfectly workable web engine in the browser.

Composing HTML also e-mails requires a web-engine. Sure, you can do
that using emacs, markdown mode, a web browser for previewing, and so
on. It's a lot of work.

I don't get the point of composing HTML emails. Let's be honest
here, unless you're writing emails as part of a company with
complicated messes of html signatures or marketing emails, the only
difference between composing a plain text email and a html email for
most people is unnoticeable.

I found that not to be the case for the Outlook users to whom I sent
e-mails. I was unable to figure out how to get mutt to generate
plaintext e-mails that were rendered properly by Outlook (e.g. using a
fixed font, honoring newlines and multiple spaces, etc.) in Outlook.
It's also difficult to get plaintext e-mails to display in a
reasonable way on both a large screen and a small screen
(i.e. phone). I was not happy seeing what my plaintext, 72 column
e-mails looked like on a small phone screen.
--
Grant

[Grant Edwards]

Post by Kusoneko

Post by Grant Edwards

Post by Kusoneko

Post by Matt Connell
Don't get me wrong, I'm "team plaintext" all day every day but I'm not
going to make my life more difficult on principles.  There are hills
worth dying on but this isn't mine.

Iirc, you can setup mutt to open html emails either in a web browser
or with something like w3m.

Wait -- those are web engines. I thought the argument was that mutt
didn't need a web engine. If that was the case, then you would have no
need to set up mutt to use them to display HTML email.

Why would you want a mail client to also be a web browser when you
already have a web browser to do that job?

I don't want a mail client that's also a web browser. I want a mail
client that renders HTML. That's only a small small of what a web
browser does. Most of what a web browser does these days is provide an
environment in which to run JavaScript.

Post by Kusoneko
I will never understand the mindset of trying to include web
browsers into everything. Web browsers are massive pieces of
software, including one in everything massively increases the
compile time and resource usage of the software it's added into.

That's because they do a lot more than just render HTML.

Post by Kusoneko

Post by Grant Edwards

Post by Kusoneko
There's no need for a web engine in a mail client when you have a
perfectly workable web engine in the browser.

Composing HTML also e-mails requires a web-engine. Sure, you can do
that using emacs, markdown mode, a web browser for previewing, and so
on. It's a lot of work.

I don't get the point of composing HTML emails. Let's be honest
here, unless you're writing emails as part of a company with
complicated messes of html signatures or marketing emails, the only
difference between composing a plain text email and a html email for
most people is unnoticeable.

I found that not to be the case for the Outlook users to whom I sent
e-mails. I was unable to figure out how to get mutt to generate
plaintext e-mails that were rendered properly by Outlook (e.g. using a
fixed font, honoring newlines and multiple spaces, etc.) in Outlook.

It's also difficult to get plaintext e-mails to display in a
reasonable way on both a large screen and a small screen
(i.e. phone). I was not happy seeing what my plaintext, 72 column
e-mails looked like on a small phone screen.

--
Grant

[Jack]

Post by Matt Connell

Post by Alexe Stefan

Post by Matt Connell
Normally I would be in the chorus of "why do I need a whole entire web
engine for an email client" but I'm also in the group of people

who

Post by Alexe Stefan

Post by Matt Connell
knows full well what the answer is.

What is the answer?
Mutt doesn't need a web engine.

For the reason that you just demonstrated for the class: HTML emails.
Now, your simple mail shows just fine in a plain text only mail client,
but in my world, and I'd wager most people's world, handling HTML
messages (which includes CSS for legibility) is a necessity to some
varying degree.
Don't get me wrong, I'm "team plaintext" all day every day but I'm not
going to make my life more difficult on principles. There are hills
worth dying on but this isn't mine.

I haven't tried it in a while, but Carbonyl
(https://github.com/fathyb/carbonyl) is a web browser that runs in a
terminal. I wonder if it could be used for a text based email client
to actually display HTML emails, without the overhead of one of the big
graphics libs.

[Grant Edwards]

Post by Alexe Stefan

Post by Matt Connell
Normally I would be in the chorus of "why do I need a whole entire web
engine for an email client" but I'm also in the group of people who
knows full well what the answer is.

What is the answer?

Most of us don't like reading HTML.

Post by Alexe Stefan
Mutt doesn't need a web engine.

You must get e-mail from a different sort of sender than I do.

--
Grant