People,
On 2014-12-18 17:53, Andy Bradford wrote:
> Thus said Erwin Hoffmann on Wed, 17 Dec 2014 21:12:17 +0100:
>
>> The only major fork I know is IndiMail.
>
> This may be the only public fork, but I bet there are a lot of
> private
> forks.
>
> If I'm not mistaken, Yahoo forked qmail and I still think they are
> using
> it, but this is private code.
>
> I also think that Gmail's SMTP servers have an air of qmail to them,
> and
> I suspect that they too may have used qmail as the basis for
> building
> their service, but I could never prove it.
>
>> What I find rather puzzling is the lack of technical discussion and
>> requirements analysis among the ``qmail specialists''.
>
> Perhaps qmail fits a niche and those who use it like it in that
> niche
> already and don't find it worth the effort to compete with others?
> Maybe
> people are more interested in code origination and so we get more
> MTAs
> out there. Maybe part of the problem is that there is no concensus as
> to
> what should and shouldn't be there and nobody wants to commit to
> a
> patched qmail that is hard to remove features from. Easier to add
> than
> it is to take away?
>
> I continue to use qmail (and even recommend it for certain
> situations)
> and will continue to do so as long as it will compile.
>
>> Actually, I am a victim of this: The qmail/spamcontrol FreeBSD port
>> includes the External-Todo patch (in a version/state I can't control)
>> of Rene Oppermann glued together. It simply does not work.
>
> I don't necessarily agree with all the patches that are included in
> the
> ``jumbo'' patches so I just have my own repository beginning
> with
> vanilla qmail sources, then I patch as I see fit. If there is
> a
> conflict, I refactor until they work. I build from that for
> all
> installations where a vanilla qmail won't be suitable---I find
> that
> vanilla qmail works just fine on a private network, but for
> public
> facing SMTP more is required.
>
> What I like about qmail is it's modularity which makes it easy to
> extend
> and replace any component that doesn't do exactly what is wanted.
>
> Thanks for keeping your contributions active.
Would it possible to produce a "vanilla" version of qmail that could be
added to by producing extra, pre-compiled modules? - sort of like .so
files? I have invested so much time over the years in keeping qmail
going that I _won't_ be changing any time soon - and I have my own
little re-install script that works fine for me . . but _it would_ be
convenient to be able to just do:
yum install qmail
Isn't it possible that extra stuff like greylisting etc could be
configured from a GUI panel (producing a .conf file?) after the vanilla
yum install, that would then prompt for root user package install
permissions for the extra desired bits? If everyone could agree on APIs
then any "modules" created by others could then just be "plugged in"?
Regards,
Phil.
--
Philip Rhoades
GPO Box 3411
Sydney NSW 2001
Australia
E-mail: phil@pricom.com.au
On 2014-12-18 17:53, Andy Bradford wrote:
> Thus said Erwin Hoffmann on Wed, 17 Dec 2014 21:12:17 +0100:
>
>> The only major fork I know is IndiMail.
>
> This may be the only public fork, but I bet there are a lot of
> private
> forks.
>
> If I'm not mistaken, Yahoo forked qmail and I still think they are
> using
> it, but this is private code.
>
> I also think that Gmail's SMTP servers have an air of qmail to them,
> and
> I suspect that they too may have used qmail as the basis for
> building
> their service, but I could never prove it.
>
>> What I find rather puzzling is the lack of technical discussion and
>> requirements analysis among the ``qmail specialists''.
>
> Perhaps qmail fits a niche and those who use it like it in that
> niche
> already and don't find it worth the effort to compete with others?
> Maybe
> people are more interested in code origination and so we get more
> MTAs
> out there. Maybe part of the problem is that there is no concensus as
> to
> what should and shouldn't be there and nobody wants to commit to
> a
> patched qmail that is hard to remove features from. Easier to add
> than
> it is to take away?
>
> I continue to use qmail (and even recommend it for certain
> situations)
> and will continue to do so as long as it will compile.
>
>> Actually, I am a victim of this: The qmail/spamcontrol FreeBSD port
>> includes the External-Todo patch (in a version/state I can't control)
>> of Rene Oppermann glued together. It simply does not work.
>
> I don't necessarily agree with all the patches that are included in
> the
> ``jumbo'' patches so I just have my own repository beginning
> with
> vanilla qmail sources, then I patch as I see fit. If there is
> a
> conflict, I refactor until they work. I build from that for
> all
> installations where a vanilla qmail won't be suitable---I find
> that
> vanilla qmail works just fine on a private network, but for
> public
> facing SMTP more is required.
>
> What I like about qmail is it's modularity which makes it easy to
> extend
> and replace any component that doesn't do exactly what is wanted.
>
> Thanks for keeping your contributions active.
Would it possible to produce a "vanilla" version of qmail that could be
added to by producing extra, pre-compiled modules? - sort of like .so
files? I have invested so much time over the years in keeping qmail
going that I _won't_ be changing any time soon - and I have my own
little re-install script that works fine for me . . but _it would_ be
convenient to be able to just do:
yum install qmail
Isn't it possible that extra stuff like greylisting etc could be
configured from a GUI panel (producing a .conf file?) after the vanilla
yum install, that would then prompt for root user package install
permissions for the extra desired bits? If everyone could agree on APIs
then any "modules" created by others could then just be "plugged in"?
Regards,
Phil.
--
Philip Rhoades
GPO Box 3411
Sydney NSW 2001
Australia
E-mail: phil@pricom.com.au
