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.
>>
>
> First let me say that my method for many whitelist_auth entries does not
> allow for any phishing emails so if I find any of those, they do not get a
> whitelist_auth entry. With a properly tuned MTA in front of SA, the only
> phishing or blatant spam should be coming from compromised accounts or
> zero-hour spam which are going to be difficult to block anyway.
Yes, I should have mentioned that as well. We're not whitelisting any
end-user level accounts.
These phishes we've received were all from otherwise trusted sources
like salesforce, amazonses and sendgrid. These are examples that I
believe were previously whitelisted because of having received a phish
through these systems but have no been disabled.
whitelist_auth *@bounce.mail.salesforce.com
whitelist_auth *@sendgrid.net
whitelist_auth *@*.mcdlv.net
> My method should only be whitelist_auth'ing system-generated/bulk emails
> from reputable senders that handle abuse reports quickly and shouldn't match
> compromised accounts and "freemail" domains. It will also match commonly
> spoofed domains like fedex.com, ups.com, and banks to help block those
> phishing emails.
This also requires supporting rules that add significant points based
on their name most simply, or other more complicated rules to catch
more sophisticated phish attempts. Spammers hitting our systems are
far more sophisticated than just using "UPS" in the subject or
pretending to be from ups.com.
>> Can I also ask again about reasonable RCVD_IN_LASHBACK and
>> RCVD_IN_LASHBACK_LASTEXT scores?
>>
>
> It really depends on how much customization you have done to SA and how much
> your mail flow can handle bumping up scores. If you do some log analysis
> and find that RCVD_IN_LASHBACK and RCVD_IN_LASHBACK_LASTEXT are pretty
> accurate for your mail flow, then you can bump it up like I have to 2.2 and
> 4.2 respectively.
>
> DISCLAIMER: I am not recommending this for everyone so no flaming. Set
> these scores low and test for a few weeks or months to see how your mail
> logs line up with real spam then increase the scores as you see fit. Again,
> I do outbound mail filtering for my customers so the deep Received header
> inspection is helpful to determine compromised accounts and keep my mail
> servers off of RBLs.
Are there any numbers available from anyone's masschecks?
Thank you as always for your support.
