Custom function white/black list bug?

[Richard Lynch]

Julian Field wrote:
>
>
> Richard Lynch wrote:
>> Julian Field wrote:
>>
>> {...snip...}
>>
>>>> I guess.  I've been using "default" for our_domain.  That way it 
>>>> applies to our_domain and some of the other domains we handle.  I 
>>>> did try putting abuse at our_domain in the 
>>>> spam.bydomain/whitelist/our_domain file and it still didn't get 
>>>> white listed.  It only started working when I added the...
>>>>
>>>> return 1 if $BlackWhite->{'default'}{$to};
>>>>
>>>> ...line of code to the function.
>>> But the files are all users/domains/default recipients. Each line in 
>>> a file gives an entry for the sender going to the 
>>> user/domain/default specified by the filename.
>> Yes, I understand.  That's why I modified the code with the line 
>> above so that it would also check the recipient.
>>
>> {...snip...}
>>>> Well it doesn't work for me unless I modify the code as indicated 
>>>> in my original post.  In my case abuse at our_domain is the only 
>>>> recipient.  Looking at the code I don't see a check for the "To:" 
>>>> address in the default file.  I see a test for $from, $fromdomain, 
>>>> and $ip.  I don't see a check for $to.  That's why I added the line 
>>>> of code.
>>> There isn't the $to check as the filenames are named after the 
>>> recipient users/domains/default. The contents of each file lists the 
>>> senders that are black/whitelisted for the addresses described by 
>>> the filename.
>>>
>> So you're saying that the bydomain white list (and blacklist for that 
>> matter) entries are all aimed at allowing/disallowing senders to 
>> particular users/domains.  It has nothing to do with the recipient.
> Yes. You are aiming to achieve something I didn't design the original 
> to do, it was all intended for incoming mail to your customers. That's 
> why you need to change it, you are trying to do something different.

That's what I thought.  Thanks for the clarification.


>>   (That's what I was attempting to achieve with my modification -- 
>> which worked by the way.)
>>
>> This means there is no way for me to have a mailbox (abuse at wvnet.edu) 
>> setup such that mail from anyone at anywhere to that address gets 
>> delivered and not flagged as spam.
> Correct.
>>
>>
>> The problem is that I have people on the internet reporting spam 
>> coming from our network by sending it to abuse at wvnet.edu.  However, 
>> our helpdesk people never see it because it gets detected as spam and 
>> deleted.  I tried putting abuse in the wvnet.edu file but it doesn't 
>> work since this facility is looking for the sender (who could be 
>> anyone) rather than the recipient (abuse at wvnet.edu).
> Correct.
>>
>> I suppose I can get around this by coding a spamassassin rule that 
>> gives a large positive value for mail going to abuse at wvnet.edu.  I 
>> think I'll just handle it that way since I don't know the 
>> ramifications of the mod to the code.
> That sounds like an alternative way of doing it.
>
> The other possibility, which is considerably faster, is to put a 
> simple ruleset on "Spam Checks =" which says
>    To: abuse at wvnet.edu no
>    FromOrTo: default yes
> As you see there is more than 1 way of achieving this aim.

Yes, that occurred to me after my last post.  Duh!  I was caught up in 
the whitelist mindset.  And when I saw an indication that the first 
"To:" was checked I thought I'd found a bug.  Sorry.  The above solution 
is perfectly adequate and is what I've done.

>
> Hopefully this helps sort you out without having to change any of my 
> code at all, which is always better. I hate having to change people's 
> code to achieve something, when there is another way of doing it. Code 
> changes tend to make maintenance a nightmare in future years.
>
I agree.  I fully understand the consequences of modifying a 
distribution.  I would have to maintain the mod every time there was a 
new release.  Back in the bad ol' days of the 1980s we used to run an 
IBM mainframe OS with lots of mods (ours and other peoples).  Going from 
release to release was a major undertaking.   I vowed then to try and 
stamp out all modifications. 

Thanks for all of you efforts.  I appreciate all that you do for all of 
us.  MailScanner has made our lives the better.

Richard

-- 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: rich.vcf
Type: text/x-vcard
Size: 299 bytes
Desc: not available
Url : http://lists.mailscanner.info/pipermail/mailscanner/attachments/20060520/17980867/rich.vcf