Yahoo Groups archive

Milter-greylist

Index last updated: 2026-04-13 23:57 UTC

Message

Re: [milter-greylist] IPv6 and unknown family 54

2017-03-29 by John_Damm_S=c3=b8rensen

I was wondering whether you have LD_LIBRARY_PATH pointing to a copy of libmilter without IPv6 support?

/john


Den 29-03-2017 kl. 16:50 skrev Johann Klasek johann@... [milter-greylist]:
\ufffd

On 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
> >
>


Attachments

Move to quarantaine

This moves the raw source file on disk only. The archive index is not changed automatically, so you still need to run a manual refresh afterward.