Hugo Monteiro wrote:
> Alan Ott wrote:
>> Alan Ott wrote:
>>> Alan Ott wrote:
>>>  
>>>> Hello,
>>>>
>>>> I am currently having some trouble training my DSPAM setup. I am 
>>>> using Postfix, and am currently using the ParseToHeaders method of 
>>>> forwarding messages to spam-usern...@domian and 
>>>> notspam-usern...@domain.
>>>>
>>>> This works _some_ of the time.
>>>>
>>>> If I do "tail -f /var/dspam/system.log" and watch the DSPAM log 
>>>> while I forward some of my spam messages to spam-usern...@domain, 
>>>> SOME of them will make an entry in the log, and SOME of them simply 
>>>> will not. Re-sending the same message has the same effect (ie: 
>>>> messages that "work" will work every time, and messages that don't 
>>>> work will not work any time).
>>>>
>>>> The behavior of the log file is consistent with the figures in 
>>>> dspam_stats as well. Messages that make an entry in the log file 
>>>> will cause the numbers in dspam_stats to increment, and those that 
>>>> do not, will have no effect on dspam_stats.
>>>>
>>>> I have not been able to identify any causation. I am using 
>>>> Thunderbird, and I forward all messages as attachments.
>>>>
>>>> There does not appear to be a correlation between the size of the 
>>>> message and the behavior (ie: some small messages don't appear to 
>>>> work, and some large ones (with attachments) do work).
>>>>
>>>> I have attached my dspam.conf file here for reference, as well as 
>>>> the relevant sections of my Postfix master.cf file.
>>>>
>>>> I feel like I must be doing something wrong, but the intermittent 
>>>> nature of this behavior has me puzzled.
>>>>
>>>> I am using DSPAM version 3.8.0, configured with the very simple:
>>>>    ./configure --prefix=/usr --sysconfdir=/etc 
>>>> --with-dspam-home=/var/dspam
>>>>
>>>> Thank you for any help,
>>>>
>>>> Alan.
>>>>
>>>>     
>>>
>>> I have some more information. After checking out /var/log/maillog, I 
>>> found the following when I forward a message to spam-usern...@domain:
>>>
>>> Apr 25 13:35:08 core dspam[16636]: Unable to open file for reading: 
>>> /var/dspam/data/[EMAIL_PROTECTED]/[EMAIL_PROTECTED].sig/49f34589164016171720384.sig:
>>>  
>>> No such file or directory
>>> Apr 25 13:35:08 core dspam[16636]: Signature retrieval for 
>>> '49f34589164016171720384' failed
>>> Apr 25 13:35:08 core dspam[16636]: Unable to find a valid signature. 
>>> Aborting.
>>> Apr 25 13:35:08 core dspam[16636]: process_message returned error 
>>> -5.  dropping message.
>>>
>>> I checked, and the .sig file is not there. I also checked that it 
>>> _is_ the sig that shows up in the email.
>>>
>>> What is causing these .sig files to not be written? Every email I 
>>> send to myself from another account has the .sig files created 
>>> properly, but about 75% of my spam does not appear to.
>>>
>>> Thanks for any help,
>>>
>>> Alan.
>>>
>>>   
>>
>> The _real_ problem:
>>
>> If an email comes in with multiple recipients for the same domain, 
>> dspam will call sendmail once for each recipient, but each call will 
>> have the entire recipient list, causing recipients to get such 
>> messages twice.
>>
>> For example, a message comes in with a recipient list (TO:) of 
>> us...@domain, us...@domain. Postfix will call:
>>     /usr/sbin/sendmail -i -i -f [SENDER_EMAIL] -- us...@domain 
>> us...@domain
>> two times. This causes the message to get delivered to each user 
>> twice. Further, both of the emails delivered have different 
>> signatures, one stored under user1's database, and one stored under 
>> user2's database. Remember that both users got both emails. So now, 
>> if I forward one of these emails to spam-us...@domain, it will work. 
>> If I forward the other one, it will not, because it's data is stored 
>> under user2's database (even though it was delivered to user1).
>>
>> I changed over to daemon mode and it appears to work fine now.
>>
>> The file doc/postfix.txt says that daemon mode won't work with 
>> hash_drv.so. Someone else on a mailing list said this was because 
>> daemon mode is multithreaded. I looked in hash_drv.c and there 
>> appears to be a lot of thread-safety (mutex) and #ifdef DAEMON 
>> sections, leading me to believe that the comment in doc/postfix.txt 
>> is out of date. Is this the case? If so, the section warning about it 
>> should be removed from doc/postfix.txt.
>>
>> Alan.
>>
>>
>>
>>
>
>
> Hello Alan,
>
> Could i ask you to submit a bugreport at the Dspam BTS?
>
> Dspam BTS is available here 
> http://sourceforge.net/tracker/?atid=1126467&group_id=250683&func=browse
>
> Thank you for your input,
>
> Hugo Monteiro.
>
Submitted to the bug tracker.

Alan.


------------------------------------------------------------------------------
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensign option that enables unlimited
royalty-free distribution of the report engine for externally facing 
server and web deployment.
http://p.sf.net/sfu/businessobjects
_______________________________________________
Dspam-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dspam-user

Reply via email to