Re: libspf2 support
Ladar Levison <[email protected]> Wed, 07 Nov 2007 12:13:29 -0600
| Newsgroups | gmane.mail.spam.spf.devel |
|---|---|
| Message-ID | <[email protected]> |
memset(res_spec, 0, sizeof(struct __res_state)); Also works. [email protected] wrote: > I have since found that not all compilers (MS VS6) do not have the bzero() > function. A better fix might be using calloc() instead of malloc() + > bzero()... > > res_spec = pthread_getspecific(res_state_key); > if (res_spec == NULL) { > res_state = (struct __res_state *) > calloc(1, sizeof(struct > __res_state)); > if (res_ninit(res_state) != 0) { > SPF_error("Failed to call res_ninit()"); > } > pthread_setspecific(res_state_key, (void *)res_state); > } > else { > res_state = (struct __res_state *)res_spec; > } > > > > Please respond to [email protected] > > To: [email protected] > cc: [email protected] (bcc: Dan Mitton/YD/RWDOE) > Subject: Re: [spf-devel] libspf2 support > LSN: Not Relevant > User Filed as: Not a Record > > Scott, > > I would like to add a patch to libspf2 version 1.2.5 > > In spf_dns_resolv.c, there is routine - SPF_dns_resolv_lookup > > The code malloc's a res_state structure and then calls res_ninit( > res_state ). > > On Sun Solaris 10, as of patch 120011-14 (which updated > /lib/libresolv.so.2) it is necessary to zero out the structure before > calling res_ninit. > > According to the Sun man pages, this has always been necessary, but does > not seem to have caused problems pre-patch 120011-14. > > res_ninit man page excerpt: > > . > . > . > int res_ninit(res_state statp); > . > . > . > > DESCRIPTION > These routines are used for making, sending, and interpret- > ing query and reply messages with Internet domain name > servers. > > State information is kept in statp and is used to control > the behavior of these functions. Set statp to all zeros > prior to making the first call to any of these functions. > . > . > . > > I would like to propose adding a call to bzero() or similar functionality > to zero out the res_state structure before call res_ninit. Something > like: > > res_spec = pthread_getspecific(res_state_key); > if (res_spec == NULL) { > res_state = (struct __res_state *) > malloc(sizeof(struct > __res_state)); > bzero(res_state, sizeof(struct __res_state)); > if (res_ninit(res_state) != 0) { > SPF_error("Failed to call res_ninit()"); > } > pthread_setspecific(res_state_key, (void *)res_state); > } > else { > res_state = (struct __res_state *)res_spec; > } > > This has been tested on a Sun T2000 running Sun Solaris 10 (SunOS yddmz3 > 5.10 Generic_127111-01 sun4v sparc SUNW,Sun-Fire-T200) with Exim 4.67 and > solved our core dumping problem. > > Please let me know if there is anything else I can do to help in this > regard. > > Dan > > > > > Please respond to [email protected] > > To: [email protected] > cc: (bcc: Dan Mitton/YD/RWDOE) > Subject: Re: [spf-devel] libspf2 support > LSN: Not Relevant > User Filed as: Not a Record > > On Tuesday 16 October 2007 12:59, Hannah Schroeter wrote: >> Hi! >> >> On Tue, Oct 16, 2007 at 09:18:17AM -0700, [email protected] > wrote: >>> What is the latest libspf2 release? Is it still being supported and/or >>> developed? If not, what is my best alterative to work with Exim?? >> When I checked last (September 24th), a few patches were sent around >> on this list, but there seemed to be no central maintenance any more, >> since the last release (1.2.5, February 24th, 2005). >> >> We use libspf2 here, with a few local changes, too: >> - portability >> - DNS lookup limits adapted to RFC 4408 >> - hooks for own DNS layer (more efficient than creating an SPF_server_t >> with one of the default layers, destroying that and then substituting >> an own DNS layer there) >> - not using trusted-forwarder.org by default, from the beginning on >> - fixed result code if mx/ptr limits are exceeded >> - a few fixes of malloc/realloc/calloc error handling (not all errors >> are handled well, as that would require significant changes on the >> internal interfaces, so the library will abort on some out-of-memory >> conditions! This is also the case for the official release code, >> which also may abort with NULL pointer dereferences on OOM) > > Julian Mehnle and I recently got access to the libspf2 repository and with > > > (some) help from the previous maintainers are going to work towards > releasing > a new version that brings together the known patches. > > The Debian package has also accumulated a number of patches: > > http://packages.qa.debian.org/libs/libspf2.html > > I'd be interested to hear from everyone who has patched libspf2. > > I'd like to get: > > 1. A copy of the patch > > 2. The problem the patch is meant so solve > > 3. Testing/production experience with the patch > > Scott K ------------------------------------------- ----------------------------------------------------------------------- To unsubscribe, change your address, or temporarily deactivate your subscription, please go to http://v2.listbox.com/member/?member_id=6959932&id_secret=62509881-8cc2ab Powered by Listbox: http://www.listbox.com