@humdinger / @waddlesplash - what’s your advice for trying to get the mail_daemon working again? I’d like to checkout and build the code locally, and then replace the stock mail_daemon with one that’s got logging statements liberally scattered through the codebase.
I’m the wrong person to ask really. I can advise, however, to post to the developer mailing list if you encounter any bumps in the dev road. @axeld is the one working on the mail system last and he’ll read it there, but probably not here in the forums.
Other than that, to test your custom mail_daemon you have to stop the launch_daemon from restarting the original with launch_roster stop x-vnd.Be-POST.
Also, be aware that there are several add-ons (in /boot/system/add-ons/mail_daemon) and the libmail.so (in /boot/system/lib/libmail.so) that you may have to replace with your version too, by putting yours into the /system/non-packaged/… hierarchy.
I used to work on the spam detection software, and had to fix the mail library parsing for all those malformed MIME mail messages. Last working version of the Mail Daemon Replacement for BeOS was 3.0.3 Final, from https://sourceforge.net/projects/bemaildaemon/ and the most reliable was 2.3.0. You could get the source files from there (in CVS) and diff them with the current version to see what’s changed.
Is meant by the mail_deamon which one again as before over the terminal mails can send (went under BeOS and Zeta)?
Would be very interesting for script-based programming languages such as yab to send feedback. But also hides again the danger, a program without which one notices it, data through this deamon sent to an unknown.
I’ve managed to get logging by starting the mail preferences config panel from the terminal and from what I can see the mail is collected, but there are some errors when the mail items are written to disk.
[…] do you know how different that code is to the Haiku email daemon […]
Doing a “git log src/kits/mail” turns up a large number of changes by many people. There’s a lot of recent activity by Axel redoing IMAP. But I expect the core still is mostly the same, using the same architecture.
“Recently” he said – our mail daemon was originally developed as MDR (Mail Daemon Replacement) back when BeOS was still alive. It has then been moved into our repository, and developed further in tree. While the basic architecture is still very similar, most lines should have changed in one way or another, so a diff from the old MDR would not be very interesting to look at.
Thank you! Off the top of your head, do you have any idea why the IMAP mail receiving doesn’t work anymore? I see a download but errors thrown when the mail is written to disk.
The protocol always assumes that INBOX is subscribed. The preflet reflects this, so doesn’t allow a user to subscribe to the INBOX.
I think a fix is to remove this logic to set INBOX to always show as subscribed, so the preflet allows you to subscribe to it?
(As a side note, I always found the IMAP folder subscription system to be a little odd, as it doesn’t allow per-client subscriptions, which seems to be a critical limitation of the protocol).
It makes sense that you should be subscribed to the INBOX folder by default. However, it would make more sense to add it to the list of subscribed folder rather than having a special case for it. I’m not very familiar with the mail code, so I don’t know what’s the best place to do this.
Indeed, the special case doesn’t make sense at this point, it should instead go to the preferences, where INBOX should always be selected instead. So it’s not a recent issue, but seems depends on the mail server we talk to.
An additional note to all those thinking about contributing to the Haiku project - the process of cloning the repository, modifying and building the source, and then dropping replacements in the “non-packaged” directory was very, very simple indeed.