On 6/23/22 17:52, gil...@poolp.org wrote:
> June 23, 2022 9:02 PM, "Simon Harrison" <i...@simonh.uk> wrote:
> 
>> On Thu, 23 Jun 2022 14:54:36 -0400
>> Demi Marie Obenour <demioben...@gmail.com> wrote:
>>
>>> Is nooSMTPD available anywhere?
>>
>> That's weird. I'm sure it used to be on Gilles github:
>>
>> https://github.com/poolpOrg
>>
>> Seems to have been removed.
> 
> Hi,
> 
> Long story short, nooSMTPD (not openbsd's opensmtpd) was a custom version of 
> OpenSMTPD where I removed
> and added stuff that I could not do in OpenBSD for various reasons (legacy or 
> divergence of opinions),
> but I decided not to go on with it and simply accept that OpenSMTPD won't 
> meet all of my goals.
> 
> There are multiple reasons for that but the main ones:
> 
> a- shortly after, people started looking at the repository, asking for 
> features, asking me to make the
>    portable version, and this started looking like a real fork (which it 
> wasn't) with no benefits: I'd
>    have to do even more work than before, completely alone, and since I left 
> due to almost burning out
>    this was a nope-nope.

That is 100% valid.  Maintaining an MTA is a LOT of work.

> b- it would hurt OpenSMTPD considerably. I was always the most active 
> developer, partly because I knew
>    the entire code base and its history but also because I'm a very active 
> person that works part-time
>    leaving me many hours to work on pet projects. If I started working on 
> nooSMTPD during this time, I
>    would end up creating a fork which OpenSMTPD would be lagging behind... 
> add to this that I wouldn't
>    have the constraints of OpenBSD developers (release cycles, base libraries 
> only or rejected diffs),
>    and we end up with trees that diverge enough that the OpenSMTPD developers 
> would not necessarily be
>    able to bring back stuff from nooSMTPD to their tree. Which one would you 
> use ? if its nooSMTPD, we
>    loop back to a-
> 
> c- it would not be nice to OpenBSD / OpenSMTPD developers and we are in good 
> terms so I have no reason
>    to put them in an uncomfortable situation with a fork.
> 
> d- I'd rather right code in Golang these days when possible :-p

Same here, though Rust is even better in some cases.  Go is definitely
a much better choice than C when it comes to writing network servers,
not least because of security.

Do you by any chance have the golang code you are using anywhere?
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)

Attachment: OpenPGP_0xB288B55FFF9C22C1.asc
Description: OpenPGP public key

Attachment: OpenPGP_signature
Description: OpenPGP digital signature

Reply via email to