Milter-greylist

Maybe the 'Binaries' page should be renamed to 'Downloads', that way  
all the download links are in one place.

I tried this, but I get the message, only site administrators are  
allowed to do this.

Bill

On Mar 19, 2008, at 8:50 AM, Ondrej Valousek wrote:

> Could you add this to the Wiki as well?
> Would be a pity if it gets lost...
> Thanks,
>
> Ondrej
>
> reschauzier wrote:
>>
>> I have uploaded the finalized rpms and source rpms of milter-greylist
>> compiled with libspf2 support and the rpms for libspf2 itself to the
>> following location:
>>
>> http://files.eschauzier.org/milter-greylist/
>> <http://files.eschauzier.org/milter-greylist/>
>>
>> This directory also holds rpms for spamass-milter with an additional
>> patch to avoid scanning of messages from authenticated users (see
>> http://savannah.nongnu.org/patch/?5241
>> <http://savannah.nongnu.org/patch/?5241>)
>>
>> Rudy.
>>
>> --- In milter-greylist@yahoogroups.com
>> <mailto:milter-greylist%40yahoogroups.com>, "reschauzier"
>> <reschauzier@...> wrote:
>>>
>>> The problem has gone away after applying the res_ninit patch.
>>>
>>> Thanks for helping out!
>>>
>>> --- In milter-greylist@yahoogroups.com
>> <mailto:milter-greylist%40yahoogroups.com>, "Johann E. Klasek"
>>> <johann@> wrote:
>>>>
>>>> On Fri, Mar 14, 2008 at 09:39:32PM -0000, reschauzier wrote:
>>>>> See below. Let me know if you need additional info.
>>>>>
>>>>> Rudy.
>>>>>
>>>>> Core was generated by `/usr/bin/milter-greylist -P
>>>>> /var/milter-greylist/milter-greylist.pid -p /var/mi'.
>>>>> Program terminated with signal 11, Segmentation fault.
>>>>> #0 0x00c75f6c in free () from /lib/libc.so.6
>>>>> (gdb) thread apply all bt full
>>>>>
>>>> [..]
>>>>>
>>>>> Thread 1 (process 13734):
>>>>> #0 0x00c75f6c in free () from /lib/libc.so.6
>>>>> No symbol table info available.
>>>>> #1 0x0014ae74 in __res_ndestroy () from /usr/lib/libbind.so.4
>>>>> No symbol table info available.
>>>>> #2 0x0014b7ee in __res_vinit () from /usr/lib/libbind.so.4
>>>>> No symbol table info available.
>>>>> #3 0x0014c4f5 in __res_ninit () from /usr/lib/libbind.so.4
>>>>> No symbol table info available.
>>>>> #4 0x00a71f9c in SPF_dns_resolv_new () from /usr/lib/libspf2.so.2
>>>>> No symbol table info available.
>>>>> #5 0x00a7003f in SPF_dns_lookup () from /usr/lib/libspf2.so.2
>>>>> No symbol table info available.
>>>>> #6 0x00a709b2 in SPF_dns_get_client_dom () from
>> /usr/lib/libspf2.so.2
>>>>> ---Type <return> to continue, or q <return> to quit---
>>>>> No symbol table info available.
>>>>> #7 0x00a7003f in SPF_dns_lookup () from /usr/lib/libspf2.so.2
>>>>> No symbol table info available.
>>>>> #8 0x00a7916f in SPF_server_get_record () from
>> /usr/lib/libspf2.so.2
>>>>> No symbol table info available.
>>>>> #9 0x00a785c3 in SPF_request_query_mailfrom () from
>>> /usr/lib/libspf2.so.2
>>>>> No symbol table info available.
>>>> [..]
>>>>
>>>> This seems really to be the known res_ninit() issue (see my  
>>>> previous
>>>> posting): The caller have to provide a private data segment, for
>>>> subsequent resolver calls. If this memory area will be not
>> cleared, some
>>>> resolver-library versions are assuming non-zero values of the data
>>>> structure as pointer to not returned malloc'd memory from the past
>> - but
>>>> this assumption is wrong if the malloc'd memory was not wiped with
>> zeros
>>>> and garbage is in the memory segment. Trying to apply free on  
>>>> such a
>>>> surious pointer leads to a segmentation fault (sooner or later).
>>>>
>>>> Hope this helps.
>>>>
>>>> Johann K.
>>>>
>>>
>>
>>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>