People,
On 2014-12-24 01:29, Joshua Megerman wrote:
>>> It would be really helpful to stick our wisdom together and provide a
>>> solid qmail-based mailing solution for the community.
>>
>> as you might have noticed I'm very sceptic about that.
>
> I've been considering writing my own MTA in the qmail-style of
> operations
> for several years, and recently have been doing some more focused
> research
> on what all the pieces that I'd need to consider are (at least from an
> RFC/spec standpoint, as well as a few language options). My problem
> with
> the existing qmail code is that DJB went out of his way to a) avoid
> using
> system libraries (substdio anyone?) and b) write code that is difficult
> to
> understand at a glance (e.g., lots of single-letter variables). Add to
> that the fact that different peoples' patches are all in different
> styles,
> plus the need to keep using DJBs idiosyncrasies and I think what qmail
> needs to move forward is a complete rewrite. Whether or not I'm going
> to
> do it is another question entirely :)
>
> One of the things that I am seriously considering is having a plugin
> architecture (as someone earlier had asked about)
That was me . .
> to allow additional
> functionality to be added without having to patch and recompile the
> whole
> system, possibly without even having to touch the existing code.
Exactly . .
> Some of
> the ESMTP extensions lend themselves to this easily, some not so
> easily,
> and a couple of them not at all, but the latter are probably worth
> incorporating into the base anyway (like Enhanced Status Codes). I'd
> be
> happy to share my findings either with the list or individuals if
> there's
> interest, and if I do start coding I'd also be happy to collaborate
> with
> others to make things happen, but I'll cross that bridge if I get
> there.
>
> I've used qmail for almost 20 years, and patched/maintained my working
> codebase for 10+, but like others have said it's getting long in the
> tooth. The fact that it's public domain hasn't done it any favors -
> DJB
> didn't so much "release" qmail as he abandoned it, and while those of
> us
> who use and like qmail aren't bothered by that, most mainstream
> distributors aren't going to want to touch something that has no
> developer
> support and no apparent future...
I have been on the mailing list for this [new] MTA:
http://www.meta1.org
since almost the beginning - although the web site says "Last update:
2010-12-01", the last email update:
Subject: MeTA1 1.1.Alpha0.0 available
was
2014-07-14 00:54
- what do people here think of Claus Assmann's MeTA1 approach? - is
there anything there to be learned / gained by co-operating?
Regards,
Phil.
--
Philip Rhoades
GPO Box 3411
Sydney NSW 2001
Australia
Web: http://philiprhoades.org
E-mail: phr@philiprhoades.org
--
Philip Rhoades
GPO Box 3411
Sydney NSW 2001
Australia
E-mail: phil@pricom.com.au
On 2014-12-24 01:29, Joshua Megerman wrote:
>>> It would be really helpful to stick our wisdom together and provide a
>>> solid qmail-based mailing solution for the community.
>>
>> as you might have noticed I'm very sceptic about that.
>
> I've been considering writing my own MTA in the qmail-style of
> operations
> for several years, and recently have been doing some more focused
> research
> on what all the pieces that I'd need to consider are (at least from an
> RFC/spec standpoint, as well as a few language options). My problem
> with
> the existing qmail code is that DJB went out of his way to a) avoid
> using
> system libraries (substdio anyone?) and b) write code that is difficult
> to
> understand at a glance (e.g., lots of single-letter variables). Add to
> that the fact that different peoples' patches are all in different
> styles,
> plus the need to keep using DJBs idiosyncrasies and I think what qmail
> needs to move forward is a complete rewrite. Whether or not I'm going
> to
> do it is another question entirely :)
>
> One of the things that I am seriously considering is having a plugin
> architecture (as someone earlier had asked about)
That was me . .
> to allow additional
> functionality to be added without having to patch and recompile the
> whole
> system, possibly without even having to touch the existing code.
Exactly . .
> Some of
> the ESMTP extensions lend themselves to this easily, some not so
> easily,
> and a couple of them not at all, but the latter are probably worth
> incorporating into the base anyway (like Enhanced Status Codes). I'd
> be
> happy to share my findings either with the list or individuals if
> there's
> interest, and if I do start coding I'd also be happy to collaborate
> with
> others to make things happen, but I'll cross that bridge if I get
> there.
>
> I've used qmail for almost 20 years, and patched/maintained my working
> codebase for 10+, but like others have said it's getting long in the
> tooth. The fact that it's public domain hasn't done it any favors -
> DJB
> didn't so much "release" qmail as he abandoned it, and while those of
> us
> who use and like qmail aren't bothered by that, most mainstream
> distributors aren't going to want to touch something that has no
> developer
> support and no apparent future...
I have been on the mailing list for this [new] MTA:
http://www.meta1.org
since almost the beginning - although the web site says "Last update:
2010-12-01", the last email update:
Subject: MeTA1 1.1.Alpha0.0 available
was
2014-07-14 00:54
- what do people here think of Claus Assmann's MeTA1 approach? - is
there anything there to be learned / gained by co-operating?
Regards,
Phil.
--
Philip Rhoades
GPO Box 3411
Sydney NSW 2001
Australia
Web: http://philiprhoades.org
E-mail: phr@philiprhoades.org
--
Philip Rhoades
GPO Box 3411
Sydney NSW 2001
Australia
E-mail: phil@pricom.com.au