Description of problem: Mimedefang 2.74 has been released. It includes some fixes for Perl 5.12 and later. Version-Release number of selected component (if applicable): mimedefang-2.73-4 How reproducible: N/A Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Created attachment 757884 [details] Patch to bring up to 2.74... includes source patches Other than the mechanical bump of the Version, there's a new flag introduced that we'd be required to use (-y), except that it's always true. So short-circuit it at compile time. Otherwise, we could patch mimedefang-2.74/redhat/mimedefang-init.in to always invoke $prog with '-y', i.e.: daemon $PROGDIR/$prog -P @SPOOLDIR@/$prog.pid \ - -m $MX_SOCKET \ + -m $MX_SOCKET -y \ $([ -n "$LOOPBACK_RESERVED_CONNECTIONS" ] && echo "-R $LOOPBACK_RESERVED_CONNECTIONS") \ instead... Either way, we avoid ALL users having to manually add MD_EXTRA="-y" to their /etc/sysconfig/mimedefang file. We also add a trivial patch to mimedefang.pl to stop it from complaining at startup about a missing prototype on a recursive function.
Created attachment 757917 [details] Or just always pass -y via the init script
May you let me understand the details?
Don't we have a possiblity to get the version from a libmilter include file?
(In reply to Robert Scheck from comment #4) > Don't we have a possiblity to get the version from a libmilter include file? Obviously not as it seems. Which impact does it have, if we don't use -y with a non-leaking libmilter?
(In reply to Robert Scheck from comment #4) > Don't we have a possiblity to get the version from a libmilter include file? Umm.... I guess so? Diffing 8.14.3 (bug present) and 8.14.4 (bug fixed) I see that SMFI_VERSION was bumped: --- sendmail-8.14.3/include/libmilter/mfapi.h 2008-02-27 15:30:34.000000000 -0700 +++ sendmail-8.14.4/include/libmilter/mfapi.h 2009-11-05 17:57:08.000000000 -0700 @@ -7,7 +7,7 @@ * the sendmail distribution. * * - * $Id: mfapi.h,v 8.78 2008/02/27 22:30:34 ca Exp $ + * $Id: mfapi.h,v 8.80 2009/11/06 00:57:08 ca Exp $ */ /* @@ -18,7 +18,14 @@ # define _LIBMILTER_MFAPI_H 1 #ifndef SMFI_VERSION -# define SMFI_VERSION 0x01000001 /* libmilter version number */ +# if _FFR_MDS_NEGOTIATE +# define SMFI_VERSION 0x01000002 /* libmilter version number */ + + /* first libmilter version that has MDS support */ +# define SMFI_VERSION_MDS 0x01000002 +# else /* _FFR_MDS_NEGOTIATE */ +# define SMFI_VERSION 0x01000001 /* libmilter version number */ +# endif /* _FFR_MDS_NEGOTIATE */ #endif /* ! SMFI_VERSION */ #define SM_LM_VRS_MAJOR(v) (((v) & 0x7f000000) >> 24) @@ -163,9 +170,7 @@ LIBMILTER_API int smfi_settimeout __P((int)); LIBMILTER_API int smfi_setconn __P((char *)); LIBMILTER_API int smfi_stop __P((void)); -#if _FFR_MAXDATASIZE LIBMILTER_API size_t smfi_setmaxdatasize __P((size_t)); -#endif /* _FFR_MAXDATASIZE */ LIBMILTER_API int smfi_version __P((unsigned int *, unsigned int *, unsigned int *)); /*
(In reply to Robert Scheck from comment #5) > (In reply to Robert Scheck from comment #4) > > Don't we have a possiblity to get the version from a libmilter include file? > > Obviously not as it seems. Wait... what? > Which impact does it have, if we don't use -y with a non-leaking libmilter? If we don't run it with -y, then only the variables that are EXPORTED by sendmail "O Milter.macros.*" lines will be exported, I believe. No additional variables may be requested explicitly via the StandardSendmailMacros[] in mimedefang.c nor via the -a flag at run-time.
In comment #6, I do not see different versions, that could be checked via some preprocessor directive.
(In reply to Robert Scheck from comment #8) > In comment #6, I do not see different versions, that could be checked via > some preprocessor directive. -# define SMFI_VERSION 0x01000001 /* libmilter version number */ +# define SMFI_VERSION 0x01000002 /* libmilter version number */ Attaching a new fix.
Created attachment 763996 [details] Use SMFI_VERSION to know what libmilter we're built against
You noticed that the changed SMFI_VERSION depends on _FFR_MDS_NEGOTIATE only?
(In reply to Robert Scheck from comment #11) > You noticed that the changed SMFI_VERSION depends on _FFR_MDS_NEGOTIATE only? Yeah, but I thought that was also being defined in the same header file: turns out it's not. It's set during the sendmail build. Oh, well. We can still go with Attachment 757884 [details].
Okay. We will simply go with the initscript change. Nevertheless thanks for pointing the issue out, I wouldn't have noticed that. Is the prototype patch already upstream? And since when does Perl care about prototyping? I thought Perl would have invented the implicity :)
(In reply to Robert Scheck from comment #13) > Okay. We will simply go with the initscript change. Nevertheless thanks for > pointing the issue out, I wouldn't have noticed that. > > Is the prototype patch already upstream? And since when does Perl care about > prototyping? I thought Perl would have invented the implicity :) I've sent it upstream but it's not been accepted (nor rejected). Perl is only fussy about prototypes when it sees a function being defined with a prototype after that function has been referenced...
mimedefang-2.74-1.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/mimedefang-2.74-1.fc19
mimedefang-2.74-1.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/mimedefang-2.74-1.fc18
mimedefang-2.74-1.el6 has been submitted as an update for Fedora EPEL 6. https://admin.fedoraproject.org/updates/mimedefang-2.74-1.el6
mimedefang-2.74-1.el5 has been submitted as an update for Fedora EPEL 5. https://admin.fedoraproject.org/updates/mimedefang-2.74-1.el5
Package mimedefang-2.74-1.el5: * should fix your issue, * was pushed to the Fedora EPEL 5 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=epel-testing mimedefang-2.74-1.el5' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-11399/mimedefang-2.74-1.el5 then log in and leave karma (feedback).
mimedefang-2.74-1.el5 has been pushed to the Fedora EPEL 5 stable repository. If problems still persist, please make note of it in this bug report.
mimedefang-2.74-1.el6 has been pushed to the Fedora EPEL 6 stable repository. If problems still persist, please make note of it in this bug report.
mimedefang-2.74-1.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.
mimedefang-2.74-1.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.