gmane.mail.spam.spf.devel

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

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.

New libspf2 release

Scott Kitterman — 2008-10-15T16:59:08

There is (at last) a new libspf2 release. All the patches that I had collected from people were looked at and the issues addressed either by that patch or with an alternative solution (the maintainer had patches from multiple sources and sometimes they overlapped). All of you who contributed, thank you. In addition to the run of the mill bugfixes, this release also includes a security fix for a buffer overflow. I understand a CVE will be published soon at http://cve.mitre.org/cgi-bin/cvename.cgi?name=2008-2469 Because of the large numer of fixes for significant bugs (a number of memory leaks are fixed in addition to the overflow), anyone using libspf2 should seriously consider upgrading very soon. The upstream release announcement is here: http://libspf2.org/index.html The new version can be downloaded from here: http://libspf2.org/download.html A number of vendors and distributors that provide libspf2 were contacted and are in varying states of providing updates. For Ubuntu Linux a patch to correct the buffer overflow has been uploaded for all supported releases and will be published soon. I intend to upload the new 1.2.8 to the current development release and will explore backporting it to earlier releases. Scott K

InterPC.SPF + test suite

Frank Ellermann — 2008-08-21T08:52:07

Hi, after we have sorted out how test suite test results *could* be published I added InterPC.SPF 1.1 with a link to Eddy's article here (the test output is attached). [Eddy, if InterPC.SPF 1.2 passes 2008.08 please say so.] For Julian's and Stefano's results I linked the entries to archived articles here. For pyspf I didn't find the announcement wrt 2008.08. Frank

Mail::SPF 2.006

Julian Mehnle — 2008-08-18T07:37:07

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Mail::SPF 2.006 has been released, bringing a few minor features and bug fixes: http://search.cpan.org/dist/Mail-SPF-v2.006/ 2.006 Debian packages (2.006 not yet uploaded to Debian): http://files.mehnle.net/software/mail-spf-perl/debian/ Changes: # Legend: # --- = A new release # + = Added a feature (in a backwards compatible way) # ! = Changed something significant, or removed a feature # * = Fixed a bug, or made a minor improvement - --- 2.006 (2008-08-17 22:00) Mail::SPF: + Added result object factory facility to Mail::SPF::Server in order to support the sub-classing of Mail::SPF::Server and Mail::SPF::Result. See README for details. Any code throwing Mail::SPF::Result(::*) objects directly should stop doing so and use Mail::SPF::Server::throw_result() instead. + Added a "query_rr_types" option to Mail::SPF::Server's constructor as a way to disable the retrieval of either "SPF" or "TXT" type RRs. I wouldn't make use of it if I was you! ! Changed the "max_void_dns_lookups" option's default value from undef (i.e., no limit) to a limit of 2. This should not cause any problems in practice, however see the "max_void_dns_lookups" option's description for specifics on what this entails. * Match patterns greedily by reversing the order of the regexp alternatives from RFC 4408. Thus TLDs with dashes (e.g., ".xn--wgv71a") are now correctly matched. * In macro strings, expand '%-' to '%20' rather than '-'. Thanks to Frank Ellermann for providing a test case for the RFC 4408 test suite that inadvertently exposed this bug. > Mail::SPF::Result: + Added new received_spf_header_name() constant specifying the "Received- SPF" header field name, which may (and usually should) be overridden by custom result sub-classes; see the documentation. * Generate "identity=mailfrom" rather than "identity=mfrom" in "Received-SPF" header field. * name() now returns a symbolic result name instead of the trailing part of the result class name. This should not have no impact on 3rd-party code. * Added new isa_by_name() method as an equivalent to the built-in isa(), taking a result name instead of a class name. Provides a superset of the is_code() method's functionality. * Substituted ";"s for "&" parameter separators in the openspf.org "Why?" page URL in the default authority explanation string. This change is purely cosmetic. * Minor documentation fixes and improvements. Miscellaneous: * We ship and pass the 2008.08 release of the official RFC 4408 test suite. * While officially declaring a build-requirement of Module::Build >= 0.2805 (which, if not satisfied, Module::Build itself will warn about, but not abort), do not strictly require it. If the META.yml file generated during package building is irrelevant, e.g., if we are being built by a package management/build system such as Debian's, then 0.26 is sufficient. * Recommend NetAddr::IP >= 4.007, as it has all $& and $` removed for better performance; see . For changes in previous versions, see: http://search.cpan.org/src/JMEHNLE/Mail-SPF-v2.006/CHANGES -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkipJqMACgkQwL7PKlBZWjvgLACePibN1SRHjsmsnBtHIFuBCZXK IewAnR1gIi49jjWeAzMl6hTwcP165mS9 =lWiy -----END PGP SIGNATURE-----

Test file changes

Boyd Lynn Gerber — 2008-08-17T16:34:29

So is the .tar.gz file the best one to use? I want to add this to the openSUSE BS. Thanks, -- Boyd Gerber zenez.com> ZENEZ1042 East Fort Union #135, Midvale Utah 84047

RFC 4408 test-suite 2008.08 released

Julian Mehnle — 2008-08-17T12:36:53

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 A new release, 2008.08, of the RFC 4408 test-suite has been finalized: http://www.openspf.org/Test_Suite It is recommended that you verify that your implementations still conform to the updated test-suite, and update them if necessary. A quote from the changelog (changes since the 2007.05 release): # Legend: # --- = A new release # ! = Added a test case or otherwise tightened a requirement, possibly # causing implementations to become incompliant with the current # test-suite release # - = Removed a test case or otherwise relaxed a requirement # * = Fixed a bug, or made a minor improvement - --- 2008.08 (2008-08-17 16:00) ! "invalid-domain-empty-label", "invalid-domain-long", "invalid-domain-long-via-macro" test cases: A that is a valid domain-spec per RFC 4408 but an invalid domain name per RFC 1035 (two successive dots or labels longer than 63 characters) must be treated either as a "PermError" or as non-existent and thus a no-match. (In particular, those cases can never cause a TempError because the error is guaranteed to reoccur given the same input data. This applies likewise to RFC-1035-invalid s that are the result of macro expansion.) Refined descriptions and comments to that end. The no-match behavior can be inferred by analogy from 4.3/1 and 5/10/3. The spec reference to 8.1/2 is bogus because the formal grammar does not preclude such invalid domain names. ! The "exp= without domain-spec" controversy has been resolved; it must be a syntax error. Tightened "exp-empty-domain" test case accordingly. ! Added test cases: ! "a-dash-in-toplabel": may contain dashes. Implementations matching non-greedily may get that wrong. ! "a-only-toplabel", "a-only-toplabel-trailing-dot": Both "a:museum" and "a:museum." are invalid syntax. A bare top-label is insufficient, with or without a trailing dot. ! "exp-no-txt", "exp-dns-error": Clearly, "exp=" referring to a non-existent TXT RR, or the look-up resulting in a DNS error, must cause the "exp=" modifier to be ignored per 6.2/4. ! "macro-mania-in-domain": Test macro-encoded percents (%%), spaces (%_), and URL-percent-encoded spaces (%20) in . ! "macro-reverse-split-on-dash": Test transformation of macro expansion results: splitting on non-dot separator characters, reversal, number of right-hand parts to use. - Removed "a-valid-syntax-but-unqueryable" test case. It is redundant to the "invalid-domain-empty-label" test case. - Relaxed "multispf1" test case: If performed via live DNS (yes, some people do that!), this test may be ineffective as DNS resolvers may combine multiple identical RRs. Thus, tolerate the test failing in this manner. * Adjusted "multispf2" test case: Avoid combination of multiple identical RRs by using different capitalization in intentionally duplicate RRs. * Renamed test cases: a-numeric-top-label -> a-numeric-toplabel a-bad-toplab -> a-bad-toplabel -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkioG2UACgkQwL7PKlBZWjsH7QCeKgchvwAFYQYpgyCKnXNojqhI x5UAn0K7qpRJbZ4CAHINF7/4p5wy4b+0 =auCa -----END PGP SIGNATURE-----

Problem with scripts in python-postfix-policyd-spf

Boyd Lynn Gerber — 2008-08-15T16:30:41

Hi, With the latest openSUSE 11.0 and newer they use rpmlint and require that all script have a shabang in them. That is #! /usr/bin/python python-policyd-spf.noarch: W: script-without-shebang /usr/lib/policyd-spf/policydspfsupp.py python-policyd-spf.noarch: W: script-without-shebang /etc/cron.d/policyd-spf This text file has executable bits set or is located in a path dedicated for executables, but lacks a shebang and cannot thus be executed. If the file is meant to be an executable script, add the shebang, otherwise remove the executable bits or move the file elsewhere. -- Boyd Gerber zenez.com> ZENEZ1042 East Fort Union #135, Midvale Utah 84047

InterPC.SPF 1.2

Eddy Minet — 2008-07-01T11:08:09

Hi, Here are last changes made in the library : - Integrates Alphons van der Heijden .NET resolver to execute DNS queries. So windows api is not used anymore and Dns lookup is fully managed code. - Consists now in a one file dll assembly. (InterPC.DnsLookup not needed anymore) - Dns lookup accepts all ascii chars. Scott, bmsi.com does not have an SPF RR type record. SPF is contained in a TXT (16) record. (verified in http://www.kitterman.com/getspf.py). There is still a point for wich I am not sure. It is about the HELO question. In the RFC there is : - the domain portion of the "MAIL FROM" or "HELO" identity. So if we check HELO smtp.myserver.com, the domain to check is it 'myserver.com' or 'smtp.myserver.com'. Because in the test 'mx-empty' (example), the mailfrom is empty so, for the test to pass, the helo parameter mail.example.com must be checked (example.com has no zone data). (Hope I am clear enough, does somebody speak French ? ;-)) ------------------------------------------- Sender Policy Framework: http://www.openspf.org Modify Your Subscription: http://www.listbox.com/member/ Archives: http://www.listbox.com/member/archive/1007/=now RSS Feed: http://www.listbox.com/member/archive/rss/1007/ Powered by Listbox: http://www.listbox.com

Proposed test cases (%_, %%. %-)

Frank Ellermann — 2008-06-28T16:50:07

description: Macro mania comment: >- DNS supports any octet. SPF directly supports printable ASCII and space, indirectly any octet, but no dots within labels. tests: outer-space: description: >- SPF supports spaces in DNS labels with a macro. spec: 8.1/6 helo: you get mail from my pc host: 1.2.3.4 mailfrom: "don't panic"< at >outer-space.test result: pass percent-hack: description: >- SPF supports percent in DNS labels with a macro. spec: 8.1/6 helo: this is no IDNA or SMTP test host: 1.2.3.4 mailfrom: yamamoto< at >outer-space.xn--zckzah result: pass inner-space: description: >- There is also a percent-encode space, go figure. spec: 8.1/6 helo: inner%space.xn--zckzah host: 1.2.3.5 mailfrom: "" result: pass zonedata: outer-space.test: - SPF: v=spf1 include:inner%_space.test -all inner space.test: - A: 1.2.3.4 outer-space.xn--zckzah: - SPF: v=spf1 include:inner%%space.xn--zckzah -all inner%space.xn--zckzah: - A: 1.2.3.4 - SPF: v=spf1 include:inner%-space.xn--zckzah -all inner%20space.xn--zckzah: - A: 1.2.3.5

InterPC.SPF and Test Suite

Eddy Minet — 2008-06-27T09:17:37

about 'invalid-domain-long-via-macro' test

Eddy Minet — 2008-06-26T10:54:45

I have a problem with the following test in the test suite : invalid-domain-long-via-macro: description: >- target-name that is a valid domain-spec per RFC 4408 but an invalid domain name per RFC 1035 (long label) must be treated as non-existent. comment: >- A domain label longer than 63 characters that results from macro expansion in a mechanism target-name is valid domain-spec syntax (and is not even subject to syntax checking after macro expansion), even though a DNS query cannot be composed from it. In analogy to 4.3/1 and 5/10/3, the mechanism should then be treated as a no-match. spec: [4.3/1, 5/10/3] helo: "%%%%%%%%%%%%%%%%%%%%%%" host: 1.2.3.4 mailfrom: foo< at >t12.example.com result: fail SPF record for t12.example.com is : v=spf1 a:%{H}.bar -all Regarding the comment, I think that macro expansion of the 'a' mechanism should result in a too long domain name label but when expanding '%{H}.bar' the result is '%%%%%%%%%%%%%%%%%%%%%%.bar' which does not contains label longer than 63 chars .. ? Can someone help ? ------------------------------------------- Sender Policy Framework: http://www.openspf.org Modify Your Subscription: http://www.listbox.com/member/ Archives: http://www.listbox.com/member/archive/1007/=now RSS Feed: http://www.listbox.com/member/archive/rss/1007/ Powered by Listbox: http://www.listbox.com

InterPC.SPF & Test Suite

Eddy Minet — 2008-06-25T07:22:22

Hi all, InterPC.SPF is a .NET library that has just been added to the openspf.org implementations page. In order to submit it to the Yaml test suit I searched for a .NET Yaml parser. I found 2 but no one of them were able to parse correctly the rfc4408-tests.yml file. If someone know about a working implementation of Yaml reader in .NET (or COM) please tell me. I'm currently making a quick written class file to do the job but don't have time to develop a full compliant Yaml library. To continue . Eddy Minet ------------------------------------------- Sender Policy Framework: http://www.openspf.org Modify Your Subscription: http://www.listbox.com/member/ Archives: http://www.listbox.com/member/archive/1007/=now RSS Feed: http://www.listbox.com/member/archive/rss/1007/ Powered by Listbox: http://www.listbox.com

Quoted pairs in the test suite

Frank Ellermann — 2008-04-14T07:14:48

Hi, does the SPF test suite cover oddities like MAIL FROM:<"\b\a\c\k\s\l\a\s\h"< at >test.example"> ? In the SPF I18N entry of the FAQ I claim that implementations will evaluate a %{l} local part macro as "backslash" (without the quotes), but actually I'm far from sure that implementations get within right. Frank

Issues building on Fedora 8...

Michael Breuer — 2008-04-06T20:31:20

Ok, maybe I'm brain dead... just tried installing libspf2 1.2.5 and spfmilter 1.0.8 on a Fedora 8 machine. libspf2 builds and installs OK. When I try to build and install spfmilter, the configure fails on an undefined reference to SPF_destroy_config. The following issues seem to be in libspf2: 1. missing includes for and : /usr/include/spf2/spf_request.h:29: error: field 'ipv4' has incomplete type /usr/include/spf2/spf_request.h:30: error: field 'ipv6' has incomplete type 2. /usr/include/spf2/spf_server.h:23:30: error: spf_dns_internal.h: No Such file or directory Fixed by removing inclusion of spf_dns_internal.h from spf_server.h When I correct those errors, I then get (again, spfmilter configure step)... from config.log: spfmilter-1.0.8/conftest.c:57: undefined reference to SPF_destroy_config When I tried digging further, I noted that the definition of SPF_config_t was missing. Still digging, but perhaps someone already has a fix?

Python SPF policy server for Postfix available at backports.org for Debian Etch (Stable)

Scott Kitterman — 2008-03-20T20:16:59

For those of you running Debian Stable (Etch) interested in doing SPF checking with Postfix, you can now get what you need from etch-bakcports. Instructions for enabling etch-backports can be found here: http://backports.org/dokuwiki/doku.php?id=instructions Once you've set up the repository, all you should need to do is: apt-get install postfix-policyd-spf-python (add sudo or su to root) That should drag in everything you need. Instructions for integrating the policy server with your Postfix can be found in man policyd-spf. Scott K

Another Permerror heuristic

Stuart D. Gathman — 2008-03-19T18:32:23

When Pyspf get a PermError, it still attempts to get a "best guess" result by heuristically examining the SPF record. I just realized another simple addition to its bag of heuristics. When the error is "two or more SPF records (or TXT records), simply evaluated both, and if the results agree, that is the best guess - a pretty confident guess at that. I would only apply this for 2 records, since that would arise in practice when naively updating SPF records. In fact, this would be another tweak for SPFv3: only report PermError for exactly 2 SPF records (v3 should not use TXT) when the results disagree. If both records get the same result, that is an official result.

SPF debian package configuration problem

Alejandro Cabrera Obed — 2008-01-04T16:46:22

Dear people, I've have a mail server composed by DebianEtch + Postfix 2.3.8-2 + Courier 4.1. I've installed SPF as a Debian package in order to check incoming mail, I do this: # apt-get install libmail-spf-query-perl # wget http://www.openspf.org/source/software/postfix-policyd-spf-perl/tags/2.005.tar.gz After that I untar and take the postfix-policyd-spf-perl and I do: # mv postfix-policyd-spf-perl /usr/local/sbin/smtpd-policy.pl # chmod 755 /usr/local/sbin/smtpd-policy.pl In /etc/postfix/main.cf I add: smtpd_recipient_restrictions = ... reject_unknown_sender_domain reject_unauth_destination check_policy_service unix:private/policy ... I /etc/postfix/master.cf I add: policy unix - n n - - spawn user=nobody argv=/usr/bin/perl /usr/local/sbin/smtpd-policy.pl Finally: # postfix reload But after that when I send a message from Hotmail to my local mail account, the message doesn't come to me and I get this errors in my /var/log/mail.log file: Jan 4 12:38:24 mail postfix/smtpd[12439]: NOQUEUE: reject: RCPT from blu139-omc3-s6.blu139.hotmail.com[65.55.175.206] 451 4.3.5 Server configuration problem; from=hotmail.com> to=company.com.ar> proto=ESMTP helo= Jan 4 12:38:24 mail postfix/smtpd[12439]: disconnect from blu139-omc3-s6.blu139.hotmail.com[65.55.175.206] Jan 4 12:39:05 mail postfix/spawn[12350]: warning: command /usr/bin/perl exit status 2 Jan 4 12:39:05 mail postfix/smtpd[12348]: warning: premature end-of-input on private/policy while reading input attribute name Jan 4 12:39:06 mail postfix/smtpd[12348]: warning: problem talking to server private/policy: Connection reset by peer What can be the problem with SPF ??? How can I check if it works OK ??? Special thanks Alejandro ------------------------------------------- Sender Policy Framework: http://www.openspf.org Archives: http://v2.listbox.com/member/archive/1007/=now RSS Feed: http://v2.listbox.com/member/archive/rss/1007/ Modify Your Subscription: http://v2.listbox.com/member/?member_id=6959932&id_secret=81838459-9d934f Powered by Listbox: http://www.listbox.com

IPv6 root DNS change

Stuart D. Gathman — 2008-01-04T15:00:52

Noted on slashdot: Just before year's end, ICANN/IANA sent out a short message saying that "on 4 February 2008, IANA will add AAAA records for the IPv6 addresses of the four root servers whose operators have requested it." There are some potential bugs in spf libraries that should be tested: http://www.icann.org/committees/security/sac018.pdf Especially those that use their own resolver, e.g. pyspf + pydns. Firewall appliances that look inside DNS packets are also suspect. (And one pyspf user has already had trouble with a firewall that didn't like DNS request packets with a TID of 0.)

Segmentation fault in libspf2-1.2.5

Paweł Zuzelski — 2007-12-27T15:01:37

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Sorry for my english. I hope you will understand me: I'm trying to configure exim-4.69 with libsfp2-1.2.5. Exim receives Segmentation Fault while processing spf condition. It crashes every time when the message should not be delivered. I'm using 64-bit Debian Etch. I tried to use: * Exim-4.68 and Exim-4.69 (compiled with libspf2, libsrs_alt and openldap) * Debian package libspf2-1.2.5-2 * libspf2-1.2.5 compiled from sources with the default options (i.e. configure; make; make install) Every time there was the same problem. I tried to debug it: 11:48:15 root< at >lookout:~# gdb /usr/local/bin/exim GNU gdb 6.4.90-debian Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "x86_64-linux-gnu"...Using host libthread_db library "/lib/libthread_db.so.1". (gdb) run -bh 192.168.0.191 Starting program: /usr/local/bin/exim -bh 192.168.0.191 [Thread debugging using libthread_db enabled] [New Thread 46972538120544 (LWP 10604)] **** SMTP testing session as if from host 192.168.0.191 **** but without any ident (RFC 1413) callback. **** This is not for real! 220 betamail.touk.pl ESMTP Thu, 27 Dec 2007 11:48:47 +0100; TouK e-mail server. helo z 250 betamail.touk.pl Hello z [192.168.0.191] mail from: z< at >onet.pl 250 OK rcpt to: pzz< at >touk.pl (matched "touk.pl") Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 46972538120544 (LWP 10604)] 0x00002ab8a4b2b9e0 in memset () from /lib/libc.so.6 (gdb) backtrace #0 0x00002ab8a4b2b9e0 in memset () from /lib/libc.so.6 #1 0x00002ab8a48a4d2f in SPF_record_expand_data (spf_server=, spf_request=0x5e0120, spf_response=, data=0x5e00b4, data_len=0, bufp=0x7fff06ec6ec0, buflenp=0x7fff06ec6ecc) at spf_expand.c:169 #2 0x00002ab8a48a53e7 in SPF_server_get_default_explanation (spf_server=0x5e48c0, spf_request=0x0, spf_response=0x400000141, bufp=0x7fff06ec6ec0, buflenp=) at spf_get_exp.c:57 #3 0x00002ab8a48a55e6 in SPF_request_get_exp (spf_server=0x5d4fb0, spf_request=0x5e0120, spf_response=0x5e4230, spf_record=0x5e4850, bufp=0x7fff06ec6ec0, buflenp=0x7fff06ec6ecc) at spf_get_exp.c:141 #4 0x00002ab8a48a68c0 in SPF_i_done (spf_response=0x5e4230, result=, reason=, err=SPF_E_SUCCESS) at spf_interpret.c:77 #5 0x00002ab8a48a75d0 in SPF_record_interpret (spf_record=0x5e4850, spf_request=0x5e0120, spf_response=0x5e4230, depth=0) at spf_interpret.c:1166 #6 0x00002ab8a48a9735 in SPF_request_query_record (spf_request=0x5e0120, spf_response=0x5e4230, spf_record=0x5e4850, err=SPF_E_SUCCESS) at spf_request.c:224 #7 0x00002ab8a48a9a77 in SPF_request_query_mailfrom (spf_request=0x5e0120, spf_responsep=0x5c3c08) at spf_request.c:255 #8 0x000000000046aa71 in spf_process () #9 0x000000000040a63f in acl_check_condition () #10 0x00000000004085de in acl_check_internal () #11 0x0000000000408c43 in acl_check () #12 0x0000000000455049 in smtp_setup_msg () #13 0x000000000042024f in main () (gdb) I do not know what kind of information should I attache. Do you need my exim configuration? Or my exim/libspf binaries? - -- Pawel Zuzelski TouK s.k.a. e-mail: pzz< at >touk.pl jid: pzz< at >touk.pl gpg key: http://user.touk.pl/pzz/gpg.key -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHc75XWK8wWdpYeNARAj9WAJ4vEokI6KiqHIxYaEOsIkZzEllccwCfcEaI X8j0ZNBWHYssYCIeBypxynk= =nKJ3 -----END PGP SIGNATURE----- ------------------------------------------- Sender Policy Framework: http://www.openspf.org Archives: http://v2.listbox.com/member/archive/1007/=now RSS Feed: http://v2.listbox.com/member/archive/rss/1007/ Modify Your Subscription: http://v2.listbox.com/member/?member_id=6959932&id_secret=79495715-4f1173 Powered by Listbox: http://www.listbox.com

libspf2 memory corruption (?)

Bas Verhoeven — 2007-12-10T16:50:07

Hi, I am experiencing problems with libspf2. I have been trying various versions starting with libspf2 1.0.4, and so far every version I tried (up to the debian libspf 1.2.5.dfsg-4) is having the same problems. In this case I'm trying with libspf 1.2.5.dfsg-4 (debian). I have tried to contact the Debian maintainer for this package, but haven't received any reply. The RT bug thingie also seems to be broken, so I really hope some of you can help me out. I am using this library like this: SPF_server_t *spf_server = SPF_server_new(SPF_DNS_CACHE, 0); SPF_request_t *spf_request = SPF_request_new(spf_server); SPF_response_t *spf_response = NULL; But as soon as I initialize the server, memory gets corrupted: [PC: 0xb7d478cc] (Thread 0) **FREE_NULL** Freeing null pointer. Stack trace where the error occurred: realloc() (interface) SPF_record_compile_macro() SPF_record_compile() SPF_server_set_localpolicy() SPF_server_new() main() autoreply.c, 116 **Memory corrupted. Program may crash!!** The above dump is from the binary debian package, below is the dump from the (debian) source package: [spf_compile.c:107] (Thread 0) **FREE_NULL** >> *datap = realloc(*datap, size); Freeing null pointer: *datap Stack trace where the error occurred: SPF_c_ensure_capacity() spf_compile.c, 107 SPF_c_mech_add() spf_compile.c, 831 SPF_record_compile() spf_compile.c, 1260 SPF_server_set_localpolicy() spf_server.c, 226 SPF_server_new() spf_server.c, 127 main() autoreply.c, 116 **Memory corrupted. Program may crash!!** Most of the times my program survives, but sometimes my program does indeed crash after it does some memory operations, so I have the feeling my code checker (Insure++) is right and libspf2 is indeed trying to free a null pointer. I was wondering if I am doing something wrong. If not, is this a known bug, and if so is there a fix available? Please let me know if you need any additional information. Sincerely yours, Bas Verhoeven ------------------------------------------- Sender Policy Framework: http://www.openspf.org Archives: http://v2.listbox.com/member/archive/1007/=now RSS Feed: http://v2.listbox.com/member/archive/rss/1007/ Modify Your Subscription: http://v2.listbox.com/member/?member_id=6959932&id_secret=74245753-fa7cfc Powered by Listbox: http://www.listbox.com