People,
It is better to start a new thread for this discussion - I should
describe what I am trying to achieve with this table:
https://docs.google.com/spreadsheets/d/1Pj30OWYkbF3a5f8V6h2pTRCIabuzYYYcHu9pjcKg63o/edit#gid=0
I am NOT trying to list ALL the features of ALL the Qmail variants - I
am try to compare them by listing features that the other variant(s)
DON'T have so that someone like me, who can build a Qmail server from
sources, can say, for example: "I can do it from scratch for myself but
now I just want something I can install and run immediately as a Docker
image" - and choose the appropriate variant. Another deciding factor
might be the need to be able to install from RPMs etc - most variants
will do most of the things that people want - I want to be able to see
the DIFFERENCES.
On 2016-09-17 18:19, Kai Peter wrote:
> eQmail and indimail have TLS support too. And btw, spamdyke can be
> used for auth and TLS too.
OK, If all variants can do TLS happily - I should remove that line of
comparison.
> Your comparison is quite to flat to me.
Do you mean "too flat"? - in any case I am not sure what you mean by
"flat".
> Short, indimail is the most
> complete one including a lot of features.
These are the things I want people to tell me . .
> s/qmail has the "best"
> implementation of IPv6, but requires ucspi-ssl for TLS - it can't be
> used with (x)inetd w/o additional software (TLS/SSL).
OK, I will add that as a comparison line.
> eQmail is - more
> or less - a patched netqmail with sripped source code and some
> replacements/addons from my daily practice.
I switched fairly painlessly from netQmail to eQmail a while ago - now I
want to do a comparison.
> At least the most benefit
> of (X)qmail for me is its modularity. Thus it can be easily expanded
> through (inividual) wrappers to nearly any feature. Just in short.
Examples would be good.
> But independant of your sheet I think your initial problem is a config
> issue. I would expect this will happen with all qmail variants as well
> with any other MTA.
OK . .
> the root cause is to feature out and understand
> what is going wrong. Not to read standard docs as a variant of LWQ or
> switching to another software.
I don't understand what you are getting at . .
> And one more: a lot of the people who
> are running a MTA (public) shouldn't do this - IMHO. This would
> prevent all from a lot of trouble. This is not a qmail issue. Call me
> the bad one.
Again, I don't understand what you are getting at here either . .
Thanks,
Phil.
--
Philip Rhoades
PO Box 896
Cowra NSW 2794
Australia
E-mail: phil@pricom.com.au
It is better to start a new thread for this discussion - I should
describe what I am trying to achieve with this table:
https://docs.google.com/spreadsheets/d/1Pj30OWYkbF3a5f8V6h2pTRCIabuzYYYcHu9pjcKg63o/edit#gid=0
I am NOT trying to list ALL the features of ALL the Qmail variants - I
am try to compare them by listing features that the other variant(s)
DON'T have so that someone like me, who can build a Qmail server from
sources, can say, for example: "I can do it from scratch for myself but
now I just want something I can install and run immediately as a Docker
image" - and choose the appropriate variant. Another deciding factor
might be the need to be able to install from RPMs etc - most variants
will do most of the things that people want - I want to be able to see
the DIFFERENCES.
On 2016-09-17 18:19, Kai Peter wrote:
> eQmail and indimail have TLS support too. And btw, spamdyke can be
> used for auth and TLS too.
OK, If all variants can do TLS happily - I should remove that line of
comparison.
> Your comparison is quite to flat to me.
Do you mean "too flat"? - in any case I am not sure what you mean by
"flat".
> Short, indimail is the most
> complete one including a lot of features.
These are the things I want people to tell me . .
> s/qmail has the "best"
> implementation of IPv6, but requires ucspi-ssl for TLS - it can't be
> used with (x)inetd w/o additional software (TLS/SSL).
OK, I will add that as a comparison line.
> eQmail is - more
> or less - a patched netqmail with sripped source code and some
> replacements/addons from my daily practice.
I switched fairly painlessly from netQmail to eQmail a while ago - now I
want to do a comparison.
> At least the most benefit
> of (X)qmail for me is its modularity. Thus it can be easily expanded
> through (inividual) wrappers to nearly any feature. Just in short.
Examples would be good.
> But independant of your sheet I think your initial problem is a config
> issue. I would expect this will happen with all qmail variants as well
> with any other MTA.
OK . .
> the root cause is to feature out and understand
> what is going wrong. Not to read standard docs as a variant of LWQ or
> switching to another software.
I don't understand what you are getting at . .
> And one more: a lot of the people who
> are running a MTA (public) shouldn't do this - IMHO. This would
> prevent all from a lot of trouble. This is not a qmail issue. Call me
> the bad one.
Again, I don't understand what you are getting at here either . .
Thanks,
Phil.
--
Philip Rhoades
PO Box 896
Cowra NSW 2794
Australia
E-mail: phil@pricom.com.au