I was wondering whether you have LD_LIBRARY_PATH pointing to a copy of libmilter without IPv6 support?
/john
\ufffdOn Wed, Mar 29, 2017 at 11:06:55AM +0200, John Damm S\ufffdrensen john@... [milter-greylist] wrote:
> From this thread it seems to be libmilter compiled without IPv6 support.
>
> https://www.mail-archive.com/dkim-milter-discuss@.../msg01042.html
> >we are using milter-greylist "version 4.6.2" on an CentOS 6 host with
> >sendmail 8.14.7.
> >The host has an IPv4 and an IPv6 address (dual stack); sendmail was
> >compiled with IPv6 support.
> >
> >Milter-Greylist works fine with emails from an IPv4 host but when an
> >email from an IPv6 hosts arrives we get back this error messages:
> >
> >Mar 15 12:53:41 tyr milter-greylist: greylist:
> >connect[140270896260864]: unknown family 54
> >Mar 15 12:53:41 tyr sendmail[13836]: v2FBrfvM013836:
> >milter_sys_read(greylist): cmd read returned 0, expecting 5
> >Mar 15 12:53:41 tyr sendmail[13836]: v2FBrfvM013836: Milter
> >(greylist): to error state
> >
> >Any ideas?
As already mentioned, but with some details on it ...
libmilter is probably statically linked to milter-greylist *and* is not
compiled with NETINET6 support. The libmilter client milter-greylist
tries to gather information about the incoming connection in module
engine.c (command "connectinfo").
Check with (ajust path as needed)
ldd /usr/bin/milter-greylist
Fedora-based systems seem to have linked their applications with the
static libmilter library.
I have a second milter too, which I compiled by myself. This one (similar
as in your case) has libmilter dynamically linked ...
ldd shows
linux-vdso.so.1 => (0x00007fff575ff000)
libmilter.so.1.0 => /usr/lib64/libmilter.so.1.0 (0x00007f2e96180000) <--- probably missing above
libpthread.so.0 => /lib64/libpthread.so.0 (0x00000038a8800000)
libdb-4.8.so => /lib64/libdb-4.8.so (0x00000038ad200000)
libc.so.6 => /lib64/libc.so.6 (0x00000036df000000)
/lib64/ld-linux-x86-64.so.2 (0x00000036dec00000)
This may be the cause for the discrepancy you have seen.
Regards,
Johann
> >
> >CU
> >
>