Linux serverNETWORK ADMINISTRATIONSsmtp server liux

Interactive Go Code Review: mox mail server

I set out to roast the mox mail server, by Mechiel Lukkien, but found myself second-guessing many of his choices, rather than able to make conclusive statements about them. So I invited him on to just discuss his code directly. Watch our discussion.

Project repository: https://github.com/mjl-/mox

For more about the mox package, listen to our interview with Mechiel on the Cup o’ Go podcast: https://cupogo.dev/episodes/go-1-20-is-out-also-new-golangci-lint-new-full-stack-email-server-and-conf42-virtual-event-cfp

source by Boldly Go

linux smtp server

3 thoughts on “Interactive Go Code Review: mox mail server

  • Thanks for highlighting this application; as a veteran of too many Postfix+etc+etc+etc installations, including providing managed services for clients in past years, I was reluctant to do it again for myself as a bit of a move from putting all my eggs in a big-co cloud.

    But I did do it about a year ago; prior experience certainly made the process much easier for me than a newbie, but it's arcane enough setup and some of the tools and configuration approaches are… different and different (I am looking at you, rspamd).

    I've never liked how fragile the system feels, even though mine trucks along fine. I certainly would not recommend anyone but the dedicated do it on their own with the palette of services one needs plus DNS-related knowledge.

    Seeing Mox both impressed me and scared me due to the scope, but what the heck I dove in last night and migrated three domains, five users and a couple of dozen aliases. The import tool worked flawlessly. All in all it was pretty straightforward and I see Mox rejecting senders that it should reject, plus I have new features like auto discovery and an admin UI that I did not have before (although maybe didn't need). Very cool. I've not looked much at the code except to understand some configuration tweaks a little better; will see what I can contribute back there, in reports or in docs.
    Thanks, Mechiel!

  • The thing that stood out to me when I looked over that code base is the persistence layer: bbolt with a custom object marshal. This is potentially fine, but I really like to take backups and be able to access data and meta-data with other applications. That would be my largest concern structrually.

  • This is my favourite series! Please continue to make videos like this one.

Comments are closed.