Re: eQmail or s/qmail

I really like the eQmail-package, and certainly it's style.
We are certainly looking to use Qmail for just MTA, other things can be
better done with specialized programs.
We are using
- Dovecot/mysql for IMAP/Pop which really works fine.
- ASSP for spamfiltering
- AuthSMTP is on seperate servers (Postfix)

The only thing I "miss" is SRS.
We patched two servers once, but on both qmail-local occasionly crashed.
I never had time to investigate it further, so we don't use it for now.
However this still breaks SPF and so causing bad reputation for our
outgoing SMTP-servers.
I don't see an SRS-patch in eQmail nor s/qmail.
It is in indimail-mta, but to me indimail depends a little bit to much
on rpm's. Building Indimail ourself is patching again, and that's what
we don't want anymore.


Are there plans for an SRS-patch in eQmail or s/qmail?





Op 22-04-16 om 16:16 schreef Kai Peter:
> Spoilt for choice? My suggestion: use eQmail! ;-)
> 
> No truly, I'm wondering that there is no more response to your question.
> I see eQmail like the mentioned but never released netqmail-1.07. I made
> it cause netqmail-1.07 was never released. It includes the really needed
> enhancements only. Any other enhancements have to be done by (3rd party)
> extensions through the API's. This is the responsibility of the admin.
> Means that there will no new functionality added to the original code in
> the future - at least I don't see any reason to do so at the moment. The
> final eQmail-1.09 will be released within the next (2) weeks, so give it
> a try.
> 
> It makes the decision may be easier for you if you know where eQmail
> will go in the future. Mainly it will be stripped down by removing some
> overhead. Less code, less risk of bugs. As an example qmail-pop3d will
> be removed from standard installation because of the "Guninski" bug and
> the availability of other/better POP3/IMAP servers. Overall eQmail will
> be a core MTA with improved user (admin) friendliness in the future.
> Code changes will be reduced to fixes in case there will be a need for.
> I will publish a road map after next final release.
> 
> I will bundle some of my extensions in my upcoming openqmail suite and
> will add more step by step.
> 
> Anyway, you have do decide along your needs, experience and preferences.
> IMHO individual patching haven't to be necessary anymore.
> 
> On 2016-04-21 11:00, Pascal Nobus wrote:
>> Since the previous century we are running several mailservers on qmail,
>> serving around 6000 domains with about 4000 mailboxes.
>>
>> All systems are based on the original Qmail-1.03, with the standard
>> patches, and all run on a single UID, based on Paul Greggs howto:
> Whatever you define as "standard patch".  Beware that things (can)
> differ between the "big" patches.
>> https://pgregg.com/projects/qmail/singleuid/
> Assuming this means that you are using qmail's user mechanism through
> users/assign. No need to start from scratch with eQmail.
>>
>> Spamfiltering is done in front of Qmail, with assp. So no hookups needed
>> for this. (assp listens to port 25, qmail to port 125)
>>
>> Ezmlm is also in use.
> Beware of the user-ext delimiter before compile. However, ezmlm is an
> extension which can be replaced by an alternative (I prefer mlmmj).
>>
>>
>> Because of the several patches the last years (some have TLS, other
>> IPv6, some both, some none of these), we want to make a new fresh start
>> with compiling qmail on our servers.
>> Our systems are mixed-OS's, most run on Slackware, some of them on
>> CentOS, so I want to compile the things myself.
> Any (modern) linux is fine to compile. For the BSD's some things differs
> a bit. Btw, I have no interest to support historical operating systems
> running in the basement of some guys.
>>
>>
>> Which package should we follow?
>> eQmail, s/qmail, or are there others?
>>
>> Any tips are welcome.
> Maybe you will have a look at my eQmail road map:
> https://blog.dyndn.es/doku.php/blog/2015/06/18_my_eqmail_roadmap (and
> around)
> 
> regards
> Kai
>>
>> Best regards,
>> Pascal Nobus
>