SuSE-8.1: [snip] postfix-1.1.12-12.i586.rpm
Is there any plan to update the postfix package to a newer version at all? Seems like we're all trying to get 1.1.12 fixed, while the current version is 2.0.13.
Have you tried running the version 2 of postfix from SuSE 8.2?
*I* have my 2.0.10. The urls i posted before are "unofficial" SuSE rpms and you find rpms for 8.0, 8.1, 8.2 (now it's postfix 2.0.13). Works okay for me. But i had a hell of a time with my configuration until i found out that obviously SASL/TLS wasn't working correctly in the distro's rpm and that the unofficial one fixed it at once without any hassle. Didn't want to sound too demanding - just the delay between 1.1.12 and 2.0.13 (along with the bug i had encountered and the current vulnerability) made me think of at least posting the urls to the unofficial rpms ;-)
That's always a good idea, and mentioning that the URL points at _unofficial_ RPMs is another good one. :-) Why we do not update versions of packages in SuSE products? (Peter, this question might be worth being included in the FAQ on www.susesecurity.com...) A modern Linux distribution is a set of packages that are carefully configured, built, configured (again, this time runtime), tested, modified and tested again. Packages are built using one another, causing the packages to depend on others. These package dependencies make some packages so-called leaf-packages, and others non-leaf-packages (from inside the depedency tree). The level of dependency can range up to 10-15 iterations. Adding a new version to a package that other packages depend on (such as the openssl library, or the glibc) can cause unpredictable side effects. Even though the packages may claim that they are downwards compatible, side effects can't be avoided in most cases. Sometimes, packages even have bug-to-bug compatibility, which causes the dependency tree to crack if one of several bugs gets fixed. Package version updates are possible in some cases where a change in the behaviour of a package does not have any effect on another package - this must be a leaf package. SuSE can't predict if the resulting incompatibilities break someone's scripts and programs, but it happens that we are willing to take that risk. The rule however is to maintain the maximum level of proficiency and to change only what is a bug. Thanks, Roman.