Red Hat Bugzilla – Bug 460555
upgrade to sendmail 8.14?
Last modified: 2010-10-23 00:08:50 EDT
The latest RHEL5 release, 5.2, ships with sendmail 8.13.8 (the latest 8.13 sendmail release).
However, sendmail 8.14 has been available since 2007-01-31. (The latest 8.14 sendmail release is 8.14.3, released on 2008-05-03.)
Sendmail 8.14 has many desirable enhancements over sendmail 8.13. In particular, the libmilter interface has been significantly extended, and several of the new libmilter features (e.g., the ability to change the envelope sender address) are features we very much want.
To my knowledge, any sendmail.mc files written for sendmail 8.13 should be forwards-compatible with sendmail 8.14. Furthermore, since Red Hat ships sendmail with only static versions of libmilter, libsm, and libsmutil, there is no possibility of breaking applications linked against sendmail 8.13 libraries.
RHEL5 is still in the "Production 1" phase, which includes selected software enhancements. I think upgrading to sendmail 8.14 would be a worthwhile enhancement. Please consider it.
I've opened an enhancement request (Request Number 1853918) with Red Hat support as well.
Development Management has reviewed and declined this request. You may appeal
this decision by reopening this request.
If the reason Development Management declined this request because they viewed other enhancement requests as having higher priority, that's fine.
But if Development Management declined the request because they know (or suspect) upgrading to sendmail 8.14 will break things, then I want to know that, because we are highly inclined to spin our own 8.14 RPMs for RHEL5, and would appreciate foreknowledge of any potential landmines...
It seems to be in Raw Hide ... it would seem that perhaps the Fedora process may hold the answer as to compatibility issues, as well as the sendmail upstream, of course.
[herrold@centos-5 ~]$ srcfind -r sendmail
No idea as to opaque (properly) processes as to Development Management internals, of course, but that CRM bug or your TAC (if any) is probably a better venue
(In reply to comment #8)
> Briefly: why?
> If the reason Development Management declined this request because they viewed
> other enhancement requests as having higher priority, that's fine.
It is more about stability. It was after discussion with Quality Assurance guys and we agreed that rebasing sendmail is too risky (it's very hard to ensure that all possible user's configurations are still available without change of functionality and regressions). Therefore this enhancement request was declined. Closing that enhancement request WONTFIX.
> But if Development Management declined the request because they know (or
> suspect) upgrading to sendmail 8.14 will break things, then I want to know
> that, because we are highly inclined to spin our own 8.14 RPMs for RHEL5, and
> would appreciate foreknowledge of any potential landmines...
No, there is no known issue with sendmail 8.14 we are aware of. But any rebase of the package in stable enterprise distribution means potential risk. Sendmail is quite a big package and it is hard to guarantee that everything will be fine after rebase (think about various configurations). It should be completely ok to spin your own sendmail-8.14 rpm's for RHEL-5 - with no guarantee, though.
Thanks for suggestion for enhancement, anyway.