Re: debian testing

From: Murray S. Kucherawy <msk_at_blackops.org>
Date: Sun, 22 Nov 2009 20:00:03 -0800 (PST)

On Mon, 23 Nov 2009, Daniel Black wrote:
> ok - added some code (commented) that should fix that.

Thanks, that fixed it. I'll commit it to the trunk.

>> I'll see if I can get it working later today but it's commented out for
>> now. Is there a case where the existing test finds libmilter but that
>> doesn't contain smfi_register()?
>
> I don't imagine so. Its probably the oldist milter symbol. If it does find
> such a version its not that useful to us/

Right. But I'm wondering what problem existed that the current code
wasn't solving. Seems to me the --with-milter code we had covered the
case you pasted.

>> I've added the #ifdef for SMFIF_SETSYMLIST to opendkim.c, so that
>> should cover this case.
>
> Great - an AC_SUBST(MACRO_MANNOTICE) so the user isn't expecting it to
> work could be good too.

Well it's more complicated than that. If you set certain macros to be
tested, the MTA needs to make the available. Without smfi_setsymlist(),
this is still possible via manual MTA configuration, but the automatic
method isn't available. But not only do you need smfi_setsymlist(), but
the MTA must also have support on its side to accept the request.

Instead, I'll add something to the man pages that just says the macros
will be requested from the MTA if both the MTA and the filter support that
feature; otherwise, the MTA admin will need to make sure those macros are
sent down.

> remaining bug LIBOPENDKIM_FEATURE_STRING is constant of all features
> (enabled or not)

For me it's "libopendkim 1.2.0:" if nothing is enabled, and then things
seem to be added as I enable them. What's the intent if not that?
Received on Mon Nov 23 2009 - 04:00:27 PST