eric yes you are absolutely right. software should have all the configurations files modifiable similar to spamdyke. machines have so much more processing power and memory that the additional resources utilized in loading config files during run-time is negligible.
i dont wish to recompile from SRPMS either but i am helpless. there are so many pin pricks example : if user does not enable smtp authentication the message given is : sorry the domain is not on my list of allowed rcpthosts -- which my customers dont understand. i would have a more friendly message like "please enable smtp authentication" similarly for chkuser -- i need to control all settings from tcp.smtp file -- individually for port 25 emails and authenticated emails. chkuser settings checking for valid email id and valid mx for authenticated users creates more problems. so what i did was create two seperate tcp.smtp files one called tcp.smtp and another called tcp.smtp.submission -- authenticated users will not have checks for email format and mx checks ... if an authenticated user via submission port sends an email with a wrong format then email bounces back after it gets into the queue. (if spamdyke is used then i would like to have two seperate configuration files one for port 25 email and the other for smtp authenticated email.) another issue : MS outlook adds single quotes and brackets to email ids. so many a user gets something like this in their address book. <'[email protected]'> ie single quotes and brackets now when qmail tries to send this email it removes the < > (brackets) but keeps the single quotes and email sending fails with error sorry could not find host : somedomain.com' note the single quote at the end of the domain name .. if possible pl modify qmail so that brackets and quotes are stripped off. if possible pl incorprate the above points in the new versions which provide for maximum flexiblity. unfortunately we cannot code but we can test on large production systems and give our feedback to you and document the steps in a systematic manner for all to use. thanks very much for your help rajesh ----- Original Message ----- From: Eric Shubert [mailto:[email protected]] To: [email protected] Sent: Sat, 06 Sep 2014 20:25:21 -0700 Subject: [qmailtoaster] Re: install qmailtoaster on centos 6.5 64 bit version On 09/06/2014 06:57 PM, [email protected] wrote: > eric > > but i wished to have a clear understanding and document the steps so > that they can be used by many others. That will be appreciated, and you're welcome to do this. Please note though that the objective of the project is to be such that rebuilding packages will be unnecessary. If someone chooses to build their own custom version of a package, they are strongly encouraged to do so on a separate machine, and *not* on a QMT host. Having a compiler and all the build environment packages on a QMT host is a fairly high security risk, in addition to being wasteful in other areas. Packages shouldn't need to be rebuilt in order to change configuration parameters, as is the case with chkuser. While I appreciate what chkuser does, I've always been disappointed that Tonino chose to implement configuration options in the manner that it's done. While this is undoubtedly most efficient from a run time standpoint, handling configuration parameters in the manner which spamdyke does it does not impact performance substantially, and is *much* easier to manage. The days of hard coding configuration options in C code should be far behind us. I intend that the next release of qmail will have settings that are appropriate for everyone, so that rebuilding in order to change configuration options would be unnecessary. I realize that some messages can be changed for other languages though. I'd like to see someone tackle internationalization in its entirety at some point, should that become a priority. > what i planned was to download the SRPMS from > http://mirrors.qmailtoaster.com/current/SRPMS/ > > and then use the same sequence of steps detailed in the install script > > http://qmailtoaster.com/distro/centos/cnt5064/cnt5064-install-script.sh > > however in the current/SRPMS/ there are multiple files for the same > package. > > EXAMPLE > > clamav-0.98.1-0.qt.src.rpm 08-Apr-2014 15:14 > clamav-0.98.4-1.qt.src.rpm 07-Jul-2014 14:43 > clamav-0.98.4-2.qt.src.rpm 08-Jul-2014 14:04 You want to use the most recent version. Having more than one version in the current tree is acceptable for yum, but at some point older versions will be limited to the archives. Note to mirror operators: This is a good reason why you should be using the --delete option. Please check that your configuration is doing so. > comparing with current/CentOS/6/x86_64/ the file that is available for > clamav is clamav-0.98.1-0.qt.el6.x86_64.rpm > > so the corresponding SRPMS package for clamav that i should use should > be clamav-0.98.1-0.qt.src.rpm These do correspond, but you want to use clamav-0.98.4-2, as that is the most recent. You should be able to tell by the highest version number or the most recent date. > is my understanding correct ? I think so, as long as you're getting the latest version. Note, there might be more recent versions in the /testing/ branch, but these are not considered stable for production use, but are usually pretty workable. Every /current/ package spends some time in the /testing/ branch (where people can install it for testing) before becoming /current/. -- -Eric 'shubes' > > > ----- Original Message ----- > From: Eric Shubert [mailto:[email protected]] > To: [email protected] > Sent: Sat, 06 Sep 2014 06:56:30 -0700 > Subject: [qmailtoaster] Re: install qmailtoaster on centos 6.5 64 bit > version > > You want the packages in the /current/ branch of the repo. > > The packages in the repo root are legacy, and are no longer maintained > in most cases. I hope to actually remove them from the root at some > point. These *-toaster packages will continue to exist in the /current/ > branch though (as they have for quite some time now). In fact, the > *-toaster files in the root are the exact same files that are in > /current/, as they're simply hard links so they don't take up more storage. > > The directory entries in the root are only there for backwards > compatibility for some non-standard scripts that some people have in the > wild. For those users please get your scripts changed *now*. I might > remove these root entries any time now. > > Thanks. > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
--------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
