gmane.mail.spam.spf.devel

Re: RT -- impossible to report bugs

Radoslaw Zielinski — 2008-12-01T15:45:56

Scott Kitterman kitterman.com> [01-12-2008 14:46]: [...] Aww, typo. Thanks.

Re: RT -- impossible to report bugs

Scott Kitterman — 2008-12-01T13:46:25

This is because you've got an excess of t's in your mail. Try libspf2< at >rt.anarres.org. Scott K

Re: Fwd: [milter-greylist] HEADS-UP: libspf2 causes milter-greylist memory leak?

Shevek — 2008-11-04T16:31:34

I do not believe we are allowed to look inside _res. I have certainly included the patch for res_ndestroy, but I believe the library authors have to make calling res_init() multiple times safe. Perhaps you could check this in your system source code? I have checked two implementations, including the one at http://www.koders.com/c/fid6F05A2EABB6A6CFB02D691F0F98DFB676F0B15E7.aspx?s=sort#L212 and both appear safe. Please see 1.2.9. Further patches will make 1.2.10 in a week or two. S.

Re: Fwd: [milter-greylist] HEADS-UP: libspf2 causes milter-greylist memory leak?

Hajimu UMEMOTO — 2008-10-29T17:39:05

Hi, hannah> Why is that needed, and how portable is that in fact, compared to hannah> calling res_init unconditionally in that place? Because, the libspf2 is not only consumer of the resolver. The res_init() might be called already before calling it from libspf2. It is enough to call res_init() once. Basically, res_init() is used in this manner on BSDs. The impact of calling res_init() again and again is unclear. I'm not sure about portability, but the _res and RES_INIT is described in resolver(8) on at least BSDs and CentOS. Sincerely, -- Hajimu UMEMOTO < at > Internet Mutual Aid Society Yokohama, Japan ume< at >mahoroba.org ume< at >{,jp.}FreeBSD.org http://www.imasy.org/~ume/

Re: include: result confusion?

Hannah Schroeter — 2008-10-28T16:07:47

Hi! Just to be public about this (I've already talked in private about this with Scott): My patch about the result code for included, but missing domains was *wrong*. Please ignore it. The code in v1.2.8 *is* correct in this respect. My local *test* was wrong. The other patch (src/libspf/spf_request.c) still stands, I think. Kind regards and sorry for any confusion, Hannah. On Wed, Oct 22, 2008 at 12:28:10PM +0200, Hannah Schroeter wrote: That's what's *wrong*. That's what's probably ok.

Re: Fwd: [milter-greylist] HEADS-UP: libspf2 causes milter-greylist memory leak?

Hannah Schroeter — 2008-10-28T13:40:44

Hi! On Tue, Oct 28, 2008 at 02:27:28PM +0100, Hannah Schroeter wrote: And I see that in the svn repository it has been done just that way (with autoconf), for that one first diff chunk. Kind regards, Hannah.

Re: Fwd: [milter-greylist] HEADS-UP: libspf2 causes milter-greylist memory leak?

Hannah Schroeter — 2008-10-28T13:27:28

Hi! On Tue, Oct 28, 2008 at 03:15:20AM +0100, Johann E. Klasek wrote: Makes sense. Kind regards, Hannah.

Re: Fwd: [milter-greylist] HEADS-UP: libspf2 causes milter-greylist memory leak?

Johann E. Klasek — 2008-10-28T02:15:20

Sorry, but this patch won't work on platform where res_* functions are real library functions, e.g on Solaris at least up to Solaris 9 ... The above fix is targeting mainly Linux or maybe NetBSD where res_* is just a macro layer. Even with checking the __RES macro value (resolver release date) this could not be catched (e.g. Solaris 9 has res_ndestroy, Solaris 8 not but both have the same __RES value!). AFIAK some autoconf stuff is needed to get the information if res_ndestroy can (should) be used! Johann Klasek

Re: Fwd: [milter-greylist] HEADS-UP: libspf2 causes milter-greylist memory leak?

Hannah Schroeter — 2008-10-27T13:52:15

Hi! On Sat, Oct 25, 2008 at 01:48:32AM +0900, Hajimu UMEMOTO wrote: I see this, but... Why is that needed, and how portable is that in fact, compared to calling res_init unconditionally in that place? Kind regards, Hannah.

Re: Fwd: [milter-greylist] HEADS-UP: libspf2 causes milter-greylist memory leak?

Hajimu UMEMOTO — 2008-10-24T16:48:32

Hi, pettai> This has been fixed by a patch in the FreeBSD Ports tree. See (and specifically pettai> patch submission [2]): pettai> ftp://ftp.freebsd.org/pub/FreeBSD/development/FreeBSD-CVS/ports/mail/libspf2/files/patch-src_libspf2_spf__dns__resolv.c,v pettai> AFAICS, this fix doesn't seem to be in the latest version of the libspf2-1.2.8 pettai> source. Maybe someone can add it to libspf2's main CVS branch instead? Here is a patch against 1.2.8: Index: src/libspf2/spf_dns_resolv.c diff -u -p src/libspf2/spf_dns_resolv.c.orig src/libspf2/spf_dns_resolv.c --- src/libspf2/spf_dns_resolv.c.origThu Oct 16 07:02:03 2008 +++ src/libspf2/spf_dns_resolv.cFri Oct 24 12:19:29 2008 < at >< at > -92,7 +92,11 < at >< at > static pthread_key_tres_state_key; static void SPF_dns_resolv_thread_term(void *arg) { +#ifdef res_ndestroy +res_ndestroy( (struct __res_state *)arg ); +#else res_nclose( (struct __res_state *)arg ); +#endif free(arg); } < at >< at > -615,7 +619,7 < at >< at > SPF_dns_resolv_new(SPF_dns_server_t *lay #if HAVE_DECL_RES_NINIT pthread_once(&res_state_control, SPF_dns_resolv_init_key); #else -if ( res_init() != 0 ) { +if ((_res.options & RES_INIT) == 0 && res_init() != 0) { perror("res_init"); return NULL; } Sincerely, -- Hajimu UMEMOTO < at > Internet Mutual Aid Society Yokohama, Japan ume< at >mahoroba.org ume< at >{,jp.}FreeBSD.org http://www.imasy.org/~ume/

Re: Fwd: [milter-greylist] HEADS-UP: libspf2 causes milter-greylist memory leak?

Scott Kitterman — 2008-10-24T16:30:59

For reasons I'm not quite sure of since I don't do C code, I have access to the libspf2 svn. I looked and this is at least partially done in SVN, but also some of the code has been refactored, so I'm not sure the rest is applicable. I'll make sure the maintainer is aware of the patch. Scott K

Fwd: [milter-greylist] HEADS-UP: libspf2 causes milter-greylist memory leak?

Fredrik Pettai — 2008-10-24T16:02:36

Hi, According to tests done by some people in the milter-greylist community, libspf2 (and possible libspf_alt) causes memory leaks on some OSes. See a cut version from the posts below: This has been fixed by a patch in the FreeBSD Ports tree. See (and specifically patch submission [2]): ftp://ftp.freebsd.org/pub/FreeBSD/development/FreeBSD-CVS/ports/mail/libspf2/files/patch-src_libspf2_spf__dns__resolv.c,v AFAICS, this fix doesn't seem to be in the latest version of the libspf2-1.2.8 source. Maybe someone can add it to libspf2's main CVS branch instead? (Someone mentioned that this also seems to be the case in the older (and perhaps unmaintained libspf_alt, but I don't know if anyone cared to test that). Regards, Fredrik

Re: include: result confusion?

Hannah Schroeter — 2008-10-22T10:28:10

Hi! On Tue, Oct 21, 2008 at 06:29:26PM -0400, Scott Kitterman wrote: My patch is against Shevek's svn, the trunk (r14023). I guess it should apply, at most with an offset in the line numbers. Alas, Shevek's svn doesn't have tags or branches to give me a notion from which revision the releases (e.g. 1.2.8) are, so I can't prepare patches against the release proper. The only tag it has is "1.0.0". I also include a patch for an issue that caused crashes in our MX that might be helpful and that isn't yet included by Shevek because he's pondering a different solution, while I think my patch is definitely better than nothing (at least our crashes are definitely gone). Kind regards, Hannah. ------------------------------------------- Sender Policy Framework: http://www.openspf.org Modify Your Subscription: http://www.listbox.com/member/ Archives: https://www.listbox.com/member/archive/1007/=now RSS Feed: https://www.listbox.com/member/archive/rss/1007/ Powered by Listbox: http://www.listbox.com

Re: include: result confusion?

Scott Kitterman — 2008-10-21T22:29:26

On Tue, 21 Oct 2008 16:59:43 +0200 Hannah Schroeter schlund.de> wrote: Ubuntu is releasing in about a week with 1.2.8. If somone could send me a diff to revert this regression in the next few days I can get it fixed. I'd really appreciate it. Scott K

Re: include: result confusion?

Hannah Schroeter — 2008-10-21T14:59:43

Hi! On Tue, Oct 21, 2008 at 10:46:30AM -0400, Stuart D. Gathman wrote: I have actually a few patches still pending with Shevek, and prepared one to revert a change that made my own test for this fail (after passing with 1.2.5). Thanks for confirming my interpretation of the RFC, so I won't have to change my local test and I will be able to keep the local change in our local revision control systems (the one for the company's development and from whence the deployed software is build, and my own for merging stuff around with S.). Kind regards, Hannah.

Re: include: result confusion?

Stuart D. Gathman — 2008-10-21T14:46:30

You are correct. I am tasked with making libspf2 pass the test suite. I am behind.

include: result confusion?

Hannah Schroeter — 2008-10-21T14:10:18

Hello! When re-evaluating test results from the new libspf2 release, I get this: I have an spf record that includes: another domain. Say foo.example -> v=spf1 ... include:bar.example ... And bar.example exists in the DNS (with other record types, such as A), but has no TXT or SPF records. I read the RFC in a way that that should result in PermError, from the table in section 5.2 (recursive result of None should cause the include mechanism to throw PermError). A test for that passed before the update (with libspf2 1.2.5), however fails now. Am I correct in my interpretation? Should this get fixed again, so that a None from the included record should result in a PermError overall? Kind regards, Hannah.

Re: New libspf2 release

Shevek — 2008-10-16T23:06:21

Bleh, I should remove that test suite entirely, it's utterly superceded by the one in the perl/ subdirectory. I forgot it was still there. S.

Re: [spf-discuss] Re: New libspf2 release

Stuart D. Gathman — 2008-10-16T18:20:52

You can reuse the SPF machinery for recognizing local addresses if the SPF library supports passing a policy without looking it up (as does pyspf). At connect, pass a policy like "v=spf1 ip4:127.0.0.0/8 ip4:192.168.0.0/16" and treat the connection as "local" on a Pass (and skip normal SPF checking). The "local" policy should be configurable. You could also reject on fail for the local policy for a consistent and configurable blacklist (e.g. use -exists: on selected ip blacklists).

Re: New libspf2 release

Hannah Schroeter — 2008-10-16T17:52:33

Hi! On Thu, Oct 16, 2008 at 09:19:35AM +0400, Eugene Crosser wrote: Dito for me. Kind regards, Hannah.

Re: New libspf2 release

Eugene Crosser — 2008-10-16T05:19:35

After the fix, I don't see problems so far. Will put the thing into "production" environment later today. Scott Kitterman wrote: Speaking of which, this looks unfortunate (and has always been this way afaik): $ make check [...] ==================================== 6 of 7 tests failed Please report to libspf2< at >anarres.org ==================================== I for one have nothing against removal. Thanks, Eugene