I have been triggered to finally switch to Haiku from macintosh partly because the macbook no longer sends email, even though I have an icloud account for all my services. Sending and receiving mail matters - it is one rubicon whose crossing marks a system being useful rather than a plaything.
To this end I have installed the Beam email client. I generated an “app specific password” and used it with server settings and username in preferences and went to fetch mail.
THE system seems to have downloaded the required number of “mails” but receive an error to the effect that “no headers found in header”. The “mails” are blank files - no attributes such as subject. My icloud account has marked all my unread mails as read - clearly they should only show as read when (if!) I could open them in Beam.
To cap things off, I wrote an email to test the smtp and it won’t send, so like my Macbook then.
Ideas? This post suggests iCloud mail deviates from mail standards, in accordance with Cupertino tradition.
The best idea would be registering an email account somewhere else, where they don’t use own proprietary stuff and only standard IMAP and SMTP.
There are really good providers around, some are even non-profit and privacy-friendly.
But I understand that it’s difficult to change your mail address everywhere.
Maybe have a look at the ported Email clients based on Qt or GTK.
They don’t look as nice, but some of them may have special workarounds for the non-standard crap of the big providers.
I pushed a fix to Beam a while ago, unfortunately Beam does not build anymore (maybe because of the transition to gcc 13?) so this fix is not present in the copy available from the depot, I suppose.
I don’t plan to fix the build and I gave up using iCloud on Haiku as I now have a dedicated Disroot account.
Just a side note: iCloud seems to follow the standard too strictly and this causes some troubles with many email clients.
Here’s a summary:
Trojità - gives the same errors as Beam, perhaps the root cause is the same
Beam - works with my patch but completely lacks support for IMAP folders
Mail daemon - is supposed to work sufficiently well with a few caveats but the connection to the server fails randomly (see bug #18579)
Claws is the only reliable choice for iCloud and with the experimental plugin I created may represent a valid choice, although I’m not a huge fan of GTK apps in general.
The best email client currently for Haiku is MailNews, but that’s only available for the 32bit version. Maybe a more recent version of Thunderbird will get ported over eventually.
I chose Beam because I thought that it better used the underlying features of the Haiku system than a ported app. Despite webmail, and I do not know how well that works on WebPositive, I think an email app is crucial to a serious OS, although my own skills are not sufficient to the task of making Beam work for me.
I will need to move away from Apple mail servers at some point, so I guess that is the next task…
Haikus own Mail app is the normal one to use. Anyhow that also needs improvements. I don‘t think it makes sense to shout „your email service is stupid!“ every time our mail application breaks. Especially with something like smartphones. You basically only get to choose between Tracking adware and apple. Having opted into a email there is not the worst thing ever… funnily enough iOS mail is one of the better email clients I‘ve used (with my own mail server anyhow)
Is this the same point as @nephele is making in his post? I was not sure if he was chiding me for a perceived diss of the makers of Beam or iCloud. I certainly got no beef with Beam and appreciate it is a hobbyist endeavour. I don’t resent Apple having spent twenty plus years as a customer (actually not true when I think about it, they have meta sized into a planet wrecking outfit whose idea of doing business is irreconcilably broken).
Agreed, from somebody who lacks the programming chips to do anything about it.
My perspective on this is not going to be very typical, as for the last couple of decades I have mostly used my own email software. (For example recently started using NetBSD as a desktop, and I suppose I could install Thunderbird or something but instead just rushed to port my software. It isn’t really so wonderful, I’m just old, one gets used to certain things.)
Anyway - ICloud follows the standard too strictly - really? That’s unique. squizzler says “blank files - no attributes such as subject.” Does that mean, attributes as in file attributes? Do the files have contents, or are zero length?
I don’t recall that I have ever tried Beam, but from the sound of things here, it should be a priority to get it working well. “Mail” is a fun idea, but it’s fundamentally flawed as a key user application. IMAP is a client/server network protocol, and the user should be operating the client itself, not a client of a daemon that serves as a client. The dependence on that daemon is really fraught, when something goes wrong, and something will always be going wrong with network client/server applications. A user desktop needs easily usable IMAP/SMTP email, and a good web browser.
“Working well” doesn’t necessarily mean, works with iCloud, or with Google mail, if there are reasons why that can’t happen, but in that case the reasons have to be well understood.
I don’t understand your point here. The fact that the default mail client is split in two executables, one that runs in the background and one that runs in the foreground, is not making implementation of IMAP any harder or easier.
You can dislike the fact that there is no inbox application and the mail daemon is trying to use Tracker for that, which I think can’t work (there will be no support for grouping messages by threads, for example, for me that instantly makes it completely unusable).
But the fact that it’s split into two executables? How can that possibly get in the way of implementing IMAP?
It’s just that the problem is not usually an implementation error here, it’s configuration, server outages, folder corruption, quotas exceeded, who knows. Mostly configuration and credentials, but anything can happen. When it happens, it’s between some background process and the network service, and it’s awkward for the user to find out what’s going on and intervene in any way. That’s why service clients are rarely done this way, with the possible exception of DNS.
The filesystem storage, I can see that it would be potentially limiting. I recently started archiving ancient messages this way, and it’s a lot better than what I had before. I’ve always had a flat, order of arrival folder structure, and have been sort of taught to distrust threading as unreliable given the hodge-podge of wacky email implementations, but that’s probably less of a problem these days. [ hah - I see I may have messed up the threading here, as I failed to enter this as a “reply.” Tsk. ]
mail_daemon has an error log that will open if something like that actually happens. The difference beside that is very minor. Beam also won‘t have implemented Imap in the UI thread… thus also needs to figure out how to display errors.
Displaying imap and smtp errors to be usefull for debugging is hard, sure. But I really don‘t see how the mail client is the problem there.
More than just threads, clicking the email button and then landing in a list that does indeed show emails but has no way to send any is confusing. I think this view should indeed be replaced by a native tailor made view. That viewing emails and sending them is in different windows is something I enjoy however. I think Beam is a great alternative if one doesn‘t want that.
Sure, my own email’s IMAP service connection runs in its own thread, naturally, but it’s an integral part of the application, so everything involves communication with the rest of the application. Architecturally it could be implemented as a separate process with little changer, and while there’s no reason to do it, it would be fine - because whether thread or process, it wouldn’t be a daemon.
I don’t understand, sorry. A daemon is just a process, there is nothing special or magic about it. AndHaiku mail client is developed as one consistent thing, made of several parts. The reason it’s run as a separate process is that allows to download mails in the background and notify you of new messages, even when the mail reader app is not running. That seems like not a bad idea, I think?
There are no problems showing error messages to the user, and better assisting the user to configure their account, with this architecture. The code and UI are dysfunctional for a variety of reasons, but having one part of the app running in the background isn’t one of them.
I didn’t persist very long with it - my own experience was not encouraging, but it was brief. Maybe it’s gong to be just what everyone needed but didn’t realize, the mail daemon that runs in the background. I’m just saying I think it’s worth the effort to keep a normal client like Beam moving forward.
Is the consensus to try setting up “Mail” or is using the same infrastructure and likely to behave the same as Beam? I initially dismissed Mail because I thought that just having emails populate a normal folder would not make it easy to handle the amount of messages that we all get nowadays.
I am glad to have helped stimulate some discussion as to email options. What is everyone else using on Haiku? Is the world moving away from email more generally? Even MS Outlook is apparently degenerating into some glorified web app nowadays.
What does “blank files” / “no attributes” mean? Do the files have no content at all, they’re size 0? Do they have apparently full email contents, but Beam did not populate the file attributes?
(I don’t know a thing about Beam, may be kind of barking up the wrong tree here if it doesn’t really deal in files or attributes, but in that case maybe there’d be better words.)
Disclaimer: I’m not an IMAP expert and my analysis could be incomplete or flawed.
Actually, I’ve written “seems to follow”.
This is based on the evidence I gathered on two unrelated problems:
BeAM used to send a UID FETCH serverID rfc822. Rfc822 seems to be supported by many modern servers but not all and is fully equivalent to BODY[]. There are a couple of posts about Thunderbird and Aspose suggesting that. However, iCloud accepts the latter and returns a well-formed list of emails, the former returns an empty list which causes Beam to fail repeatedly.
iCloud does not support the flag NEW as required by Claws. NEW is non standard and supported by Gmail and a few others, AFAIK.
My understanding is that SEEN is the right flag but iCloud adopts a failsafe strategy based also on a local timestamp to avoid incompatibility with different clients.