Yahoo Groups archive

Milter-greylist

Index last updated: 2026-04-28 23:32 UTC

Message

Re: [milter-greylist] Submitter DNS name resolution and forgery detection

2013-08-15 by Jim Klimov

On 2013-08-14 18:08, Johann Klasek wrote:
> On Wed, Aug 14, 2013 at 07:18:41AM +0200, manu@...
> <mailto:manu%40netbsd.org> wrote:
>  > Jim Klimov <jimklimov@... <mailto:jimklimov%40cos.ru>> wrote:
>  >
>  > > Okay, so here goes the third version of the un-bracketer :)
>  >
>  > I was reading it and it seemed a bit overkill to me to do the
>  > a.b.c.d -> d.c.b.a.in-addr.arpa transformation on your own. That adds
>  > many lines and still fail to support IPv6. Is your system able to use
>  > getnameinfo(), which is part of POSIX1?
>
> That's what I am wondering about too. But as mentioned in a posting
> before, the below solution under Solaris may suffer from the resolve-
> double-checking behavior. However, maybe this can be neglected in favour of
> not to reinvent the wheel and code stability ...
>
>  > Here is a sample proram to test, with both IPv4 or IPv6 addresses. It
>  > even works if you supply a DNS address.
>
> To get to program (at least) on Solaris 8 to work:
> (BSD calls err(), errx() do not exist - at least on old Solaris versions)
>
> To build with "gcc -o getaddrinfo -lsocket -lnsl getaddrinfo.c"

I used -lresolv -lsocket instead, but yes, errx() is absent and can be
replaced by a macro to do the error reporting (yes, there is more to
a "correct" output, but for a trivial case like this - the short macro
suffices):

# define errx(E, FMT...) fprintf(stderr, FMT)

I did not encounter the problems you've posted about in the past weeks
about a Solaris resolver problem, and we use a range from Solaris 8 to
10, and via OpenSolaris SXCE to current illumos-based OSes. Then again,
I am not a programmer but a sysadmin, and maybe the problems you see as
a programmer are hidden from me by programs and tools which take these
"inconvenient features" into account and work around them - so that's
why I never saw them...

As for reinventing the wheel - I do not object. I posted about some of
my reservations - whether the standard way would allow us to detect
forgery mismatches in case of multi-DNS-PTR entries; if "yes" - I can
have no objections at all :)

//Jim

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.