Any advice to start working on mail_daemon?

@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.

Any thoughts before I dive on in?

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.

Thank you very much, I shall have a look!

Off the top of your head, do you know how different that code is to the Haiku email daemon, at https://cgit.haiku-os.org/haiku/tree/src/servers/mail?

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.

No, I’m referring to the mail_daemon that sits in the background and polls the IMAP servers, unfortunately.

As per https://dev.haiku-os.org/ticket/13298 and https://dev.haiku-os.org/ticket/13229 Haiku doesn’t seem to be able to collect mail anymore.

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.

Interesting. Thanks very much; I might reach out to Axel via the mailing list before hacking around with this code too much.

“Recently” he said :slight_smile: – 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.

No idea, but I guess that would be a good showcase for our Debugger :slight_smile:

I think I found the issue (if someone wouldn’t mind confirming):

https://cgit.haiku-os.org/haiku/tree/src/add-ons/mail_daemon/inbound_protocols/imap/imap_lib/Protocol.cpp#n170

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.

Also, you can link to a specific line in a file like this: https://cgit.haiku-os.org/haiku/tree/src/add-ons/mail_daemon/inbound_protocols/imap/imap_lib/Protocol.cpp#n170

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.

It explains why the issue is sporadic; if you have subscribed to your INBOX using another mail client you’d not see the issue…

Success! Removing the “if INBOX” line and resubscribing to INBOX using the Preflet means I can now receive email from my IMAP server!

Thank you both very much for your help, @axeld and @PulkoMandy!

How do we get this fix in the source?

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.

To get your patch merged:

  • Make sure you have set your git username and e-mail
  • Create a git commit with your changes. Be sure to include a description of the changes and why they are done in the commit message.
  • Use git format-patch to create a patch with the changes
  • Attach that to a ticket at the bugtracker (dev.haiku-os.org)
  • Eventually a developer will review your changes, and if they look right, will merge them (or otherwise ask you to do further changes).

https://dev.haiku-os.org/ticket/13298 - I have uploaded the patch - I’ll wait for feedback.

Thank you very much for your help.

1 Like