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