Mailing List Archive

libspf2 support
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??

Thanks,

Dan

Dan.Mitton@ymp.gov

-------------------------------------------
-----------------------------------------------------------------------
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to http://v2.listbox.com/member/?member_id=1311533&id_secret=54142977-6c796c
Powered by Listbox: http://www.listbox.com
Re: libspf2 support [ In reply to ]
Hi!

On Tue, Oct 16, 2007 at 09:18:17AM -0700, Dan_Mitton@Notes.YMP.GOV 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)

Kind regards,

Hannah.
--
Hannah Schröter Entwicklung hannah.schroeter@1und1.de
Bei 1&1 Internet AG Ernst-Frey-Str. 9 D-76135 Karlsruhe
"Our software isn't released - it escapes, leaving a trail of bloody testers
in its wake. We relish the wailing and gnashing of our customers' teeth!"

Amtsgericht Montabaur HRB 6484

Vorstand: Henning Ahlert, Ralph Dommermuth, Matthias Ehrlich, Andreas Gauger,
Thomas Gottschlich, Matthias Greve, Robert Hoffmann, Norbert Lang, Achim Weiss
Aufsichtsratsvorsitzender: Michael Scheeren

-------------------------------------------
-----------------------------------------------------------------------
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to http://v2.listbox.com/member/?member_id=1311533&id_secret=54153312-d29795
Powered by Listbox: http://www.listbox.com
Re: libspf2 support [ In reply to ]
On Tuesday 16 October 2007 12:59, Hannah Schroeter wrote:
> Hi!
>
> On Tue, Oct 16, 2007 at 09:18:17AM -0700, Dan_Mitton@Notes.YMP.GOV 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=1311533&id_secret=54207491-fe665e
Powered by Listbox: http://www.listbox.com
Re: libspf2 support [ In reply to ]
On 16/10/2007, Dan_Mitton@notes.ymp.gov <Dan_Mitton@notes.ymp.gov> 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??

I believe that Magnus Holmgren, one of the Exim maintainers, is
maintaining the Debian package of libspf2 (correct me if I'm wrong,
Magnus...).

So you should be able to rely on ongoing compatibility with the Exim
built-in spf functionality.

Peter


--
Peter Bowyer
Email: peter@bowyer.org

-------------------------------------------
-----------------------------------------------------------------------
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to http://v2.listbox.com/member/?member_id=1311533&id_secret=54301279-8d2dc8
Powered by Listbox: http://www.listbox.com
Re: libspf2 support [ In reply to ]
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 spf-devel@v2.listbox.com

To: spf-devel@v2.listbox.com
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, Dan_Mitton@Notes.YMP.GOV
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/?&
Powered by Listbox: http://www.listbox.com



-------------------------------------------
-----------------------------------------------------------------------
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to http://v2.listbox.com/member/?member_id=1311533&id_secret=60370873-5d30a9
Powered by Listbox: http://www.listbox.com
Re: libspf2 support [ In reply to ]
On Friday 02 November 2007 10:24, Dan_Mitton@notes.ymp.gov wrote:
> Scott,
>
> I would like to add a patch to libspf2 version 1.2.5 ...

Thank you for this. I'm struggling right now to find the dedicated block of
free time I need to dive into all the accumulated patches and sort through
them, so I can't make any schedule promises. I do appreciate the input.

Scott K

-------------------------------------------
-----------------------------------------------------------------------
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to http://v2.listbox.com/member/?member_id=1311533&id_secret=60387551-5ac3be
Powered by Listbox: http://www.listbox.com
Re: libspf2 support [ In reply to ]
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 spf-devel@v2.listbox.com

To: spf-devel@v2.listbox.com
cc: scott@kitterman.com (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 spf-devel@v2.listbox.com

To: spf-devel@v2.listbox.com
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, Dan_Mitton@Notes.YMP.GOV
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/?&
Powered by Listbox: http://www.listbox.com



-------------------------------------------
-----------------------------------------------------------------------
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?&
Powered by Listbox: http://www.listbox.com



-------------------------------------------
-----------------------------------------------------------------------
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to http://v2.listbox.com/member/?member_id=1311533&id_secret=62496617-f11135
Powered by Listbox: http://www.listbox.com
Re: libspf2 support [ In reply to ]
memset(res_spec, 0, sizeof(struct __res_state));

Also works.

Dan_Mitton@Notes.YMP.GOV 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 spf-devel@v2.listbox.com
>
> To: spf-devel@v2.listbox.com
> cc: scott@kitterman.com (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 spf-devel@v2.listbox.com
>
> To: spf-devel@v2.listbox.com
> 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, Dan_Mitton@Notes.YMP.GOV
> 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=1311533&id_secret=62509770-679594
Powered by Listbox: http://www.listbox.com