e-mail client

In my mind, when something gets in such a bloated state, it cannot be said to be in a "good state".
Whereas even if something is 100% unmaintained, the code might still be in a great state.

Not all code needs to be maintained and for other projects (i.e Thunderbird), maintenance alone isn't enough, stuff probably needs to be removed, not added.

It works. It does what it is supposed to (and quite a bit bit that may be useless too).

I cannot find any other WYSIWYG HTML IMAP, half stable clients.
 
Personal opinions aside HTML emails is the agreed, accepted and expected standard in business environments since over two decades at last. So if you want to talk business, then you need to have it.
Not really. 99% of those "business" mails include nothing but text *) (plus unnecessary noise) and nobody ever complained although I keep responding text/plain :cool:

*) short of attachments of course, which every MIME-compliant mailer can handle…
 
Hosting your own email server is a lot of work (I would know, I used to work in a shop that did that). However, as long as the email client can connect to the email and handle it properly, that is frankly the user's choice. The server admin's part is limited to configuring the server to correctly accept IMAP connections from clients like Outlook or whatever the user wants to use. Back in those days, I used Pine for email, the users in the office used Outlook (properly configured), and specific brand of email client was never an issue.

FWIW, I remember the days when IMAP vs POP3 used to matter, because of hardware limitations (disk space, bandwidth, persistent connections, etc). Those days are behind us, thankfully.
 
Hosting your own email server is a lot of work
I don't think we talked about servers here? Well except maybe for a local MTA just to get the mail off the machine (which dma(8) from base does perfectly with minimal configuration).

I just had a look at neomutt's documentation and it also supports submitting a mail directly with SMTP, so you wouldn't even need that. I still like to have such a tiny MTA in place on every machine, so I can collect system mails (periodic etc…) in a central place ;)
 
I cannot find any other WYSIWYG HTML IMAP, half stable clients.
Very true and as far as I can tell Thunderbird is one of the only email clients that supports Microsoft's non-standard OAuth based "modern authentication" that so many institutions are locking themselves into.

mutt support of imap is not enough.
Why? Mutt's imap(s) implementation seems pretty good.
 
OP's opinion on Thunderbird is as follows: email client that stops receiving new mail several times per day, randomly hangs and uses 200% CPU, needs to run in some Swedish locale to display normal date yyyy-mm-dd instead of 1/2/3 because it cannot be configured otherwise, needs a plugin to normally format reply messages without this dumb blue indentation, and the plugin stops functioning after few months because they constantly change API, where the message gets smashed when pasting text from LibreOffice and needs some HTML editing skills to restore it, &c &c &c, such email client is less than ideal 😉

Claws mail switched to GTK3 since version 4. I tried Sylpheed but it can't connect to my dovecot IMAP server – “Rebuilding of the folder tree failed”.

Seamonkey emerges as an option.

Why not use a web client?

I'm testing roundcube. I used to use it many years ago and it's alright, but I'd really like to have a desktop app for that.
 
Claws mail switched to GTK3 since version 4.
Ah painful. Can you perhaps build the older version?

I do wish the ports system provided infrastructure for keeping with known good versions. Claws possibly isn't popular enough to receive a proper fork. To be fair, if the ports could somehow support the older version of Thunderbird that would probably have been a solution too.

For software I really dislike latest versions of (LibreOffice, Gimp, Blender) I tend to run an old FreeBSD 9 jail. It is a bit more of a faff than you might like but it ensures you can run the software you actually want.

As for security, the older stuff was probably better too. Worst case scenario, its in a jail anyway.
 
There might be some vulnerabilities in older versions of Gecko.

Claws has a similar tree rebuilding problem to Sylpheed. Besides they don't support HTML anyway.
 
SeaMonkey meets most of not all pf the Op requirements - the latest 2.53.9 source successfully compiles on FreeBSD 12. I've bene using it for a couple of weeks now after upgrading from 2.49.5 and only one issue has emerged which is annoying but not fatal - the inline spelling checker now fails in FreeBSD whereas in 2.49.5 and before it worked. I've logged a bug but I doubt it will get much priority as Windows, macOS and Linux are the Seamonkey project's main focus.
 
If OP needs a desktop client, why not just compile something workable from ports? Reading this thread, it really sounds like OP has a pre-compiled package, and something is seriously wrong, either with the system or the package itself, if the email client misbehaves like OP reports. One thing that comes to mind is mismatched ABI between the pre-compiled package and the base system, but I'd rather have more complete info (problematic package's version, OS version, and the like) before going any further down a path whose logic frankly rests on limited info at hand.
 
OP's opinion on Thunderbird is as follows: email client that stops receiving new mail several times per day, randomly hangs and uses 200% CPU, needs to run in some Swedish locale to display normal date yyyy-mm-dd instead of 1/2/3 because it cannot be configured otherwise, needs a plugin to normally format reply messages without this dumb blue indentation, and the plugin stops functioning after few months because they constantly change API, where the message gets smashed when pasting text from LibreOffice and needs some HTML editing skills to restore it, &c &c &c, such email client is less than ideal 😉
This is strange. I have 3 Thunderbird installations, all built from ports, and I have not seen such issues. I am using it every day with three e-mail accounts.
 
This is strange. I have 3 Thunderbird installations, all built from ports, and I have not seen such issues. I am using it every day with three e-mail accounts.
I can confirm all those (and some others) on a daily basis from ~40 installations on Windows clients here.

By far the most annoying is the long-known-but-ignored bug that Thunderbird doesn't receive/show new emails, especially because I always get nagged with this crap and our mailserver is blamed.
Another major annoyance is their bug-ridden and half-baked PGP-implementation: Instead of using the battle-tested and working GnuPG toolchain that integrates with the rest of the system, they built their own, completely isolated solution that barely works and in return blocking enigmail. I wonder what kind of paint they sniffed while deciding and implementing this travesty...
Oh, and they already had 2 critical CVEs with their implementation; one where they stored the private keys unencrypted (https://www.mozilla.org/en-US/security/advisories/mfsa2021-22/). The fact that they classified this as "low impact" tells everything about their attitude...
 
These programs read mail "offline", they download with imap the whole messages, synchronise
your client with the server, and then read mail.

Alpine downloads only what you want to read, first the headers, then a message you want to read,
then an attachment of it if you need it.

If you insist on the offline approach, you can separate the process to have more freedom in selecting your
mail program. You can use mbsync to download and synchronise messages, use a mail client
then to read the local mailbox. See here:

 
These programs read mail "offline", they download with imap the whole messages, synchronise
your client with the server, and then read mail.
that's POP3, not IMAP... knowing the difference helps you set up your email client right. FWIW, I actually disable POP3 on the server (if I have that option).
 
that's POP3, not IMAP... knowing the difference helps you set up your email client right. FWIW, I actually disable POP3 on the server (if I have that option).
I still took it that he was referring to imap. Mutt does tend to download any attachments with the individual message (though yes, it does leave the mail on the server).

Ways to improve this is is enabling cache (https://gitlab.com/muttmua/mutt/-/wikis/MuttGuide/Caching)

Though if some berk has attached 15 different images for their fancy corporate signature, Mutt does unfortunately fetch it all before opening the mail rather than upon request.

Luckily, not a deal breaker for me. It still manages to do this before something like Thunderbird would even have loaded up into memory.
 
that's POP3, not IMAP... knowing the difference helps you set up your email client right. FWIW, I actually disable POP3 on the server (if I have that option).
There are though programs around, which can copy an IMAP store locally to a Maildir file and do two-way-synchronization. In fact, mbsync is one of them, dovecot has such a tool (I guess dsync) and then there's offlineimap.

In fact so called indexing MUAs like notmuch, alot or sup have these as hard requirement because they don't pull off the emails by themselves.
 
There are though programs around, which can copy an IMAP store locally to a Maildir file and do two-way-synchronization. In fact, mbsync is one of them, dovecot has such a tool (I guess dsync) and then there's offlineimap.

In fact so called indexing MUAs like notmuch, alot or sup have these as hard requirement because they don't pull off the emails by themselves.
mail/fetchmail?

Fetchmail doesn't do exactly a two-way-sync but still, it's simple enough depending on the use case.
 
Yeah, just the email client alone is not enough, you have to be familiar with the entire TCP/IP stack to have a working implementation of an email server. If you do it right (Mail server, MTA, networking all set up to work together), then MUA's only need to be told to use IMAP/POP3 and to supply authentication credentials, no need for a messy internal implementation of the missing details. A surprising number of shops seem unaware of that, and end up leaving email administration to Google and Microsoft.
 
Yeah, just the email client alone is not enough, you have to be familiar with the entire TCP/IP stack to have a working implementation of an email server.
Plus your IP range needs to not be blacklisted by SpamHaus (that cuts out a lot of consumer ISPs). Then you need SPF and DKIM records so it isn't enough just to have a dynamic DNS or dynamic IP (most residential ISPs in the UK use these).

And then you need to have nerves of steel to just hope that your business emails are getting through to valuable clients so you don't go hungry next month ;)

In the end it just isn't worth it for me, I tend to leave emails in particular to a couple of security firms who have done nothing but massage their established trust for decades haha.
 
mail/trojita is quite good one, at least it was the last time I used it; however (if nothing was changed) it can just handle one mail account albeit you can run more than one instance at once.
 
Implementing SPF, DKIM and DMARC is no necessity. You can run your own MTA quite fine without it. Having them though might increase the possibility that the big players in the email game, so Hotmail/Outlook, Gmail and Yahoo will accept your mails just as is.

Aside that SPF, DKIM and DMARC are often confused with technologies to battle spam, which is not true. These are instead technologies which do give you the tools at hand that others are able to tell if an email pretending to come from your domain is indead the real thing or fake and therefore probably spam/phishing attack/fraud/whatever. It is a tool to maintain the reputation of your mail domain somewhat out in the wild.

Of course when some of these tools were introduced, first early adopters were mostly spammers with their own domains.
 
Back
Top