BTW, the "security issue" that the exim developers fixed in 4.84 (and which is causing these problems) is completely trivial.� As an example, Debian is not even pushing an update for this on any of their supported OSs.� See:

https://security-tracker.debian.org/tracker/CVE-2014-2972

At the bottom of that webpage, note the phrase "<no-dsa> (Minor issue)" for both Squeeze and Wheezy which means there will be no update because the issue is so minor that the Debian team decided not to bother.� So, the exim developers have decided to throw a huge monkey wrench in our works for something that is completely trivial.� That would be ok if they at least published guidelines on how to get around the incompatibilities that they introduced but they have not.

Part of my problem in fixing this issue is that I am running Debian and CentOS OSs, however, they are not even implementing this security update. So, I am going to have to install a new OS to even get to an exim version that has this update or figure out how to compile exim 4.84 on Debian or CentOS which, BTW, is NOT trivial.

Gordon



On 09/22/2014 09:08 PM, Gordon Dickens wrote:
Hi Shah,

I share your frustration.

It is highly unusual for software developers to put out new versions that are not backwards compatible without major rework which is what has happened with the exim developers on exim 4.84. Quite frankly, this entire episode pisses me off.

I am sure that I will be able to work on this and get it solved. I am not going to abandon Exim4U.� Nevertheless, I do not want to set an over optimistic expectation on when a fix will be available.

Again, if anybody wants to contribute by working on Exim4U's exim configuration file, then I would appreciate your help.� Otherwise, I will work on this as soon as I am able.

Gordon




On 09/22/2014 08:00 PM, Shamim Shahriar wrote:
On 23/09/2014 00:32, Gordon Dickens wrote:
I have not tested exim4u with exim 4.84 and I may not have the resources or time to test it for quite a while, maybe for several months.� Harald Valkanover's suggestion to comment out the headers_remove statements that are causing problems may fix the problem. Other things to try would be:

- Disable subject tagging as described in exim4u_global_spam_virus.� Subject tagging may be disabled by setting the tag score in the web interface to be equal to or greater than the discard score for each user and domain.� This may or may not solve the problem but is worth a try.

- Disable Spamassassin by setting SpamRejectScore = 100 in exim4u_global_spam_virus.� I think that this would definitely solve the problem.

- Anybody that has the inclination is welcome to debug this problem.� Please post your solution so that it can be added to the stock exim4u config.

Otherwise, you need to run an exim version prior to 4.84 until someone has the time to study this further.

FYI,

Gordon

Hi Gordon

Thank you for the suggestions. The process of disabling features or removing global options, IMHO, is not a "fix", these are workarounds; and these workarounds are nothing but compromising the much needed features/functionalities that the users need/expect. Otherwise people would have used some other combination rather than Exim with exim4u or vexim. But as you stated, Exim v4.82 seem to be the last known functional setup, and hopefully people can still get by with that.

As for testing and sending feedbacks, I think the people who are suffering the most are not really "programmers" in the classical sense and are merely end users with functional knowledge of what is supposed to do happen at different configuration changes -- much of the v4.84 is implying that their knowledge, may be gathered over many years, are uselss -- irrespective of whether that is intended or a software glitch, and that is what got everyone befuddled. I for example am not happy with the defunct headers_remove section which, despite the non-effective solutions suggested so far, works flawlessly with v4.82, and the same lookup mysql works elsewhere except for the headers_remove section. This, as I understand, is inconsistency -- which needs "fixing" as opposed to taking a detour.

Please don't get me wrong, I do appreciate your suggestions and comments, and understand your lack of time for testing and debugging -- but that does not change the fact that both the vexim and exim4u community members (and users) are left with systems that they cannot patch, even if there is a major security issue, simply because that would make their setup disfunctional and useless. And I sincerely hope that proper solution will not take so long that by that time both the vexim and exim4u users will be forced to look for an alternate.

Just my 2p

Best regards
Shah


_______________________________________________
users mailing list
users@exim4u.org
https://exim4u.org/mailman/listinfo/users




_______________________________________________
users mailing list
users@exim4u.org
https://exim4u.org/mailman/listinfo/users