Mail kit discussion

Just an opinion about BeOS/Haiku Mail handling, back in the mid 90’s the BeOS method of handling mail locally was cute (I used it full time for 3 years or so), but time has obsoleted this use case (local mail). Today, we read mails on our phones, laptops and desktops. The mails are managed on the server. My notification arrives by phone notification, and a browser pulls the mail for editing.

A guesstimate that the number of users that rely on Haiku mail local handling with attributes and such can probably counted using the fingers on one hand (ok, maybe 6 if AI generated).

Personally, I’d abandon shipping a mail service on Haiku. Just an opinion.

The mails are managed on the server.

Which make people dependent on it, and therefore on some giant, private, often foreign services, which most of the time profile mails content too.

Sure, it’s more confortable. But it’s also a captivity with long term consequences.

I’m not for removing mail_daemon or mailkit. I’m for making mail_daemon being launched at startup configurable, for people who don’t want to have local mails storage. No reason to remove a feature just because many don’t care about it.

counted using the fingers on one hand (ok, maybe 6 if AI generated).

Love this one! :smiley:

2 Likes

Personally, I think for POP3 the current mail_daemon is probably fine.

For Imap, which is a remote access protocol the support could be improved to say the least, I don’t think we should really remove mail_daemon or it’s imap support, but we should improve it.

One thing that has been discussed severall times is an imapfs, we would basically provide your emails “mounted” somewhere which exposes the remote server view directly without the need to download all emails or partially download all, if you open just two folders then for that it also only has to open those two.
Currently if you delete an email the mail kit may delete it over imap aswell, this is hard to trust from a user perspective. I don’t want me deleting some files on my disk delete something on a remote server.

Anyhow, imapfs would make this a whole lot more reliable (though we can obviously still cache all emails, or even keep all on disk in addition for user preference)
Imapfs should allow you to querry emails like people are used to, this would likely be faster too since you don’t querry the entire disk anymore.

Another pain point is IMAP IDLE, it’s not implemented yet. It is required for modern “instant” e-mail delivery, that isn’t delayed for up to 5 minutes on the minimum sync interval.

… and when we have done all that we still have the problem of the User interface. Currently, despite us using many mailing lists, the querry view is not very suited for this. You can’t view mails in context of their list, the replied to e-mail etc.

My prefferd way to fix this is a Threadview instead of the default querry, but then again maybe a threadview inside an opened e-mail (on the left side) which shows all related e-mails could work just aswell.

3 Likes

Well, that’s not always true - there are many smaller hosted email providers with IMAP access (I use one - of course, these cost money which I’m happy to pay). I also ensure I keep a full local sync for backups.

The way of how e-mail is handled on BeOS/Haiku is one of greatest things ever, I think. It allow to separate e-mail notification/fetching and e-mail reader application. So you do not need to run heavy memory consuming e-mail client with HTML rendering engine all the time. Mail being regular files allow to easily archive/backup or use different e-mail viewer software.

But another problem is that it currently do not work well. Most modern free e-mail services now do not allow access using login and password pair and require login using web page (OAuth etc.) that is currently not supported on Haiku.

10 Likes

Perhaps an imap_daemon is needed. :wink:

1 Like

Agreed, I’m using one myself, too.

But the average public is mostly using same large giant mail providers fully in remote mode, and don’t even know they can migrate their mails elsewhere without losing everything.

1 Like

Yes, an effort should be done to add newer authentication support to mail kit.

3 Likes

As one of the five mail_daemon users (for over 25 years): Objection, your honour! :slight_smile:

3 Likes

I have mentioned before, I was acquainted with the guy whose name is on all the IMAP protocol documents, and he was enthusiastic about an IMAP filesystem. In principle, anyway. I wouldn’t go there myself, but others have.

Recently, I’ve been looking at my Linux install of Thunderbird and seeing a lot of potential for resurgence of old Internet protocols. NNTP and its secure variety, bypass the need for a web browser and the HTTP-derived protocols altogether and make a more streamlined alternative to other communications media. Jabber support is also present in Thunderbird, I think.

The question regarding the relations between IMAP, POP3, NNTP and Jabber is that they are all non-web protocols and should be treated as such. Is there a common framework name that could be applied to all of them?

Correction: 6 :raised_hand:

Make that 7. :grin:

I’m using IMAP (Mail Daemon supports POP and IMAP) without any issues, at this point. This covers most use cases, I think (IMAP stays on the server). If there are other protocols that could/should be supported, I say, let’s try to add it to the daemon (whoever has that skill/experience). IMAP and POP with “Leave on Server”, download a local copy, but also leave the email on the server (at least for Inbox). Not sure how/if “Send” sync’s up or other folders, etc.