RE: Misc bits for 2.0.0

From: Murray S. Kucherawy <msk_at_cloudmark.com>
Date: Fri, 26 Feb 2010 11:52:15 -0800

> -----Original Message-----
> From: opendkim-dev-bounce_at_lists.opendkim.org [mailto:opendkim-dev-
> bounce_at_lists.opendkim.org] On Behalf Of Mike Markley
> Sent: Friday, February 26, 2010 10:33 AM
> To: opendkim-dev_at_lists.opendkim.org
> Subject: Misc bits for 2.0.0
>
> Does the OpenDKIM code depend on features available only in Lua 5.1?

As opposed to earlier versions of Lua? I don't know, but since beginning to look at it the only version I've encountered has been 5.1. 5.2 is coming out, but as yet I've not read of any projected incompatibilities. There are earlier versions available on the web site if you think we should try, but 5.1 is four years old now. I'd be fine establishing a minimum requirement there so I've modified configure.ac to fail on anything older than 5.1.

For that matter, we might want to do this with OpenLDAP too, so I've added that (minimum is 2.1.3). We already cope with older versions of OpenSSL and Sleepycat. Unfortunately OpenDBX's includes don't have any way to determine what version is installed (except when pkg-config is available), so we just have to wing it there.

> Did we ever get anywhere with figuring out the minimum autotools
> version? I'm just thinking about what docs need to be done for 2.0.0.

Since the packaging process creates ./configure and all the Makefile.in files, I don't think the end users actually need to have any of autotools installed. They only need such things if they're modifying configure.ac or any of the Makefile.am files themselves; if that's the case, I think we can reasonably expect them to have current autotools anyway. But I'd be fine documenting what I'm using to build the package if you think that's good enough.

> I also realized that I completely forgot to bring up one miltertest
> build issue I have:
> miltertest.c: In function 'mt_assert_state':
> miltertest.c:490: error: 'SMFI_PROT_VERSION' undeclared (first use in
> this function)
> miltertest.c:490: error: (Each undeclared identifier is reported only
> once
> miltertest.c:490: error: for each function it appears in.)
> miltertest.c: In function 'mt_negotiate':
> miltertest.c:1263: error: 'SMFI_PROT_VERSION' undeclared (first use in
> this function)
>
> It looks like SMFI_VERSION served this purpose in Sendmail versions
> prior to 8.14.0, at which point it was modified to specify the version
> of libmilter itself instead of the API. Proposed fix:
> --- miltertest/miltertest.c 25 Feb 2010 20:07:15 -0000 1.9
> +++ miltertest/miltertest.c 26 Feb 2010 18:28:52 -0000
> _at_@ -89,6 +89,11 @@
> #define MT_QUARANTINE 8
> #define MT_SMTPREPLY 9
>
> +/* Versions of Sendmail prior to 8.14 don't define SMFI_PROT_VERSION.
> Use SMFI_VERSION. */
> +#ifndef SMFI_PROT_VERSION
> +# define SMFI_PROT_VERSION SMFI_VERSION
> +#endif

That seems reasonable. They changed format of the version from a straight integer to a hex encoding, but a big hex number is still a lot bigger than "3" so I think it'll work. :-) I've committed it now.

> Thoughts? Does miltertest even support such an old version of the
> Milter API?

I think I need to double-check with the Sendmail people about that actually. Since miltertest implements the MTA side of things, and I spent all my time on the milter side, I'm not sure what protocol changes might be important. I know for example that truly early versions didn't have the smfi_progress() or smfi_insheader() functions, but those are milter->MTA messages so it just means the filter would never use them if built against an older library.

I'll ping someone over there for some help, but I'm not concerned enough about it to delay the release.
Received on Fri Feb 26 2010 - 19:52:25 PST