Hi,

On Tue, Feb 6, 2018 at 8:44 AM, David Jones <djo...@ena.com> wrote:
> On 02/05/2018 09:07 PM, Alex wrote:
>>
>> Hi,
>>
>>> ifplugin Mail::SpamAssassin::Plugin::DNSEval
>>>
>>> header          __RCVD_IN_BRBL  eval:check_rbl('brbl',
>>> 'bb.barracudacentral.org')
>>> tflags          __RCVD_IN_BRBL  net
>>>
>>> header          __RCVD_IN_BRBL_2        eval:check_rbl_sub('brbl',
>>> '127.0.0.2')
>>> meta            RCVD_IN_BRBL    __RCVD_IN_BRBL_2 && !RCVD_IN_BRBL_LASTEXT
>>> describe        RCVD_IN_BRBL    Received is listed in Barracuda RBL
>>> bb.barracudacentral.org
>>> score           RCVD_IN_BRBL    1.2
>>> tflags          RCVD_IN_BRBL    net
>>>
>>> header          RCVD_IN_BRBL_LASTEXT eval:check_rbl('brbl-lastexternal',
>>> 'bb.barracudacentral.org')
>>> describe        RCVD_IN_BRBL_LASTEXT    Last external is listed in
>>> Barracuda
>>> RBL bb.barracudacentral.org
>>> score           RCVD_IN_BRBL_LASTEXT    2.2
>>> tflags          RCVD_IN_BRBL_LASTEXT    net
>>>
>>> endif
>>
>>
>> You don't think these scores are a bit high for a normal installation?
>> The current default score for RCVD_IN_BRBL_LASTEXT is 1.4 and
>> RCVD_IN_BRBL doesn't otherwise exist.
>>
>> Also, does someone have a recommended score for the lashback RBL? I've
>> had it in testing for quite some time and would like to put it into
>> production with reasonable values...
>>
>
> Ok, ok.  Uncle. (Waving white flag.)  I have been sufficiently flogged so I
> have learned my lesson.  :)  This works in my highly customized SA platform
> where I have to do outbound mail filtering so deep Received header checking
> is valuable to block spam from my customer's compromised accounts.
>
> Leave out the RCVD_IN_BRBL rule above and change the RCVD_IN_BRBL_LASTEXT
> score to 1.4 to keep things the same.

I didn't mean to imply I don't agree or otherwise support your
approach. It was just unclear that this was in conjunction with that
approach of using higher spam rule scores to offset lower ham rule
scores or if it was recommended for everyone.

If you think the RCVD_IN_BRBL rule is a good one, I'd like to use it,
and while I've implemented much of your approach, I can't implement
all of it. My users raise holy hell when they receive even one phish
from an otherwise trustworthy source that's been whitelisted. It hits
on a ton of email at both ends of the spectrum - most are either very
low scoring or are already spam.

Can I also ask again about reasonable RCVD_IN_LASHBACK and
RCVD_IN_LASHBACK_LASTEXT scores?

Reply via email to