Re: Barracuda Reputation Block List (BRBL) removal from the SA ruleset
On 11 Feb 2018, at 9:54 (-0500), Benny Pedersen wrote: first query would be valid for 300 secs, but that is imho still not free, problem is that keeping low ttls does not change how dns works, any auth dns servers will upate on soa serial anyway, the crime comes in when sa using remote dns servers that ignore soa serial updates in that case ttls would keep spammers listed for 300 secs only That's not how DNS TTLs work. When a record's TTL elapses in the local name cache, it is dropped. The next query for that name and record type causes the resolver to make another query to the authoritative nameservers, which will return the same record whose TTL expired unless it has been removed from the zone. No standards-conforming DNS resolver returns NXDOMAIN based on the lack of a non-expired record in its cache and an unchanged SOA serial above the name. That would make no sense at all and require many more SOA queries than actually happen. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Currently Seeking Steady Work: https://linkedin.com/in/billcole
Re: Barracuda Reputation Block List (BRBL) removal from the SA ruleset
Dave Warren skrev den 2018-02-06 20:39: How low are the TTLs? I'm seeing 300 seconds on 127.0.0.2 which is more than sufficient time for a single message to finish processing, such that multiple queries from one message would absolutely be cached (or more likely, the first would still be pending and the second would get the same answer as the first). first query would be valid for 300 secs, but that is imho still not free, problem is that keeping low ttls does not change how dns works, any auth dns servers will upate on soa serial anyway, the crime comes in when sa using remote dns servers that ignore soa serial updates in that case ttls would keep spammers listed for 300 secs only and thats why i say 300 secs helps spammers ;; ANSWER SECTION: 2.0.0.127.bb.barracudacentral.org. 300 IN A 127.0.0.2 Maybe the TTLs are different for other records? 300 is imho to low to anything thats called free i would like to accept free if it was 3600 I am also noticing very intermittent response times, sometimes taking over a second to get a response, other times taking under 50ms. rndc querylog is my friend i just like to start a debate on why 300 is accepted as free, it does matter for non datafeeds users, but for datafeeds it does not matter at all
Re: Barracuda Reputation Block List (BRBL) removal from the SA ruleset
On Tue, 6 Feb 2018 11:38:42 -0500 Alex wrote: > On Tue, Feb 6, 2018 at 8:44 AM, David Joneswrote: ustomer'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. > > 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. I've been doing deep XBL checks for years (they come free with the zen look-ups). Initially I found that they did have a low FP rate, but that's changed as more of my mail comes through mobile (cellular) networks that use NAT to support millions of users on thousands of IPv4 addresses. I'm seeing about 10% of ham submitted from these networks hitting my deep XBL rule. > Can I also ask again about reasonable RCVD_IN_LASHBACK and > RCVD_IN_LASHBACK_LASTEXT scores? If you're going to create deep versions of more than one list it doesn't make sense to score them individually. The dominant cause of FPs on such rules is dynamic IP address reuse, being in more than one list doesn't say anything about that. Allowing a large score to build-up from multiple deep rules is reckless.
Re: Barracuda Reputation Block List (BRBL) removal from the SA ruleset
Hi, >>> whitelist_auth *@bounce.mail.salesforce.com >>> whitelist_auth *@sendgrid.net >>> whitelist_auth *@*.mcdlv.net >> >> >> I've seen enough spam sent through all three - both by way of whole >> apparently spammer-owned accounts and cracked-but-otherwise-legitimate >> accounts - that I would never blanket-whitelist whole bulk email providers. >> >> Legitimate mail sent through them generally gets through anyway IME. > > An alternative is to use "def_whitelist_auth" instead of "whitelist_auth" > That gives a -7.5 point bump to usually good sources which may occasionally > get abused. > > That way if one of their accounts gets p0wned your anti-phish rules have a > chance of pulling the junk into the spam-tagged range. Phishing is a significant concern for us. Whether or not the phish came through the customer of one of these senders or through the senders themselves, whitelisting these senders only facilitates more phishes. There was a period when it was about one being reported by a particularly large customer per day. Telling my customers that we've contacted the provider and reported the spam just isn't good enough. We also received a phish through freshdesk.com which is on the def_whitelist. It's also on the DKIMWL_WL, subtracting another -3.5 points. It was also listed in RCVD_IN_HOSTKARMA_W, but also in LASHBACK_LASTEXT and invaluement, but not enough to compensate for the negative points. I suspect it was a compromised freshdesk trial account that was managed by amazonaws and sendgrid before passing through smtp.freshdesk.com, both of which weren't whitelisted at the time.
Re: Barracuda Reputation Block List (BRBL) removal from the SA ruleset
On Tue, 6 Feb 2018, Kris Deugau wrote: Alex wrote: 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 I've seen enough spam sent through all three - both by way of whole apparently spammer-owned accounts and cracked-but-otherwise-legitimate accounts - that I would never blanket-whitelist whole bulk email providers. Legitimate mail sent through them generally gets through anyway IME. An alternative is to use "def_whitelist_auth" instead of "whitelist_auth" That gives a -7.5 point bump to usually good sources which may occasionally get abused. That way if one of their accounts gets p0wned your anti-phish rules have a chance of pulling the junk into the spam-tagged range. -- Dave Funk University of Iowa College of Engineering 319/335-5751 FAX: 319/384-0549 1256 Seamans Center Sys_admin/Postmaster/cell_adminIowa City, IA 52242-1527 #include Better is not better, 'standard' is better. B{
Re: Barracuda Reputation Block List (BRBL) removal from the SA ruleset
On 02/06/2018 01:28 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_2eval:check_rbl_sub('brbl', '127.0.0.2') metaRCVD_IN_BRBL__RCVD_IN_BRBL_2 && !RCVD_IN_BRBL_LASTEXT describeRCVD_IN_BRBLReceived is listed in Barracuda RBL bb.barracudacentral.org score RCVD_IN_BRBL1.2 tflags RCVD_IN_BRBLnet header RCVD_IN_BRBL_LASTEXT eval:check_rbl('brbl-lastexternal', 'bb.barracudacentral.org') describeRCVD_IN_BRBL_LASTEXTLast external is listed in Barracuda RBL bb.barracudacentral.org score RCVD_IN_BRBL_LASTEXT2.2 tflags RCVD_IN_BRBL_LASTEXTnet 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 I have never received phishing emails from trusted senders like those. If I did, then they would not be considered a trusted sender. We have received unsolicited junk emails from customers of theirs after someone sold our email addresses to some so-called "double opt-in" email lists that we never opted into. I have been reporting this abuse and those rogue customers are immediately locked/blocked/disabled/etc. which helps all of us. I have never received a malicious/infected/spoofing email from those, just harmless junk email. 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. Sure. What I have found effective is to train your Bayes with all spoofing emails so high BAYES rule hits will add points. The authentic emails will score very low from the whitelist_auth entry. Add in some custom regex rules in the subject and body for variations of misspellings of the spoofed brand or new zero-hour findings and this is the best protection I have been able to come up with for new spoofing/spam campaigns. 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
Re: Barracuda Reputation Block List (BRBL) removal from the SA ruleset
Alex wrote: 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 I've seen enough spam sent through all three - both by way of whole apparently spammer-owned accounts and cracked-but-otherwise-legitimate accounts - that I would never blanket-whitelist whole bulk email providers. Legitimate mail sent through them generally gets through anyway IME. -kgd
Re: Barracuda Reputation Block List (BRBL) removal from the SA ruleset
On 2018-02-05 09:12, Benny Pedersen wrote: Kevin A. McGrail skrev den 2018-02-05 16:53: I don't think that will apply will it because it will be looking up something like 1.2.3.4.bb.barracuda.blah which isn't cached. the first qurry can make a qurry with very low ttl, so it would not be cached, that means number 2 query still mkae dns query to that zone :( How low are the TTLs? I'm seeing 300 seconds on 127.0.0.2 which is more than sufficient time for a single message to finish processing, such that multiple queries from one message would absolutely be cached (or more likely, the first would still be pending and the second would get the same answer as the first). ;; ANSWER SECTION: 2.0.0.127.bb.barracudacentral.org. 300 IN A 127.0.0.2 Maybe the TTLs are different for other records? I am also noticing very intermittent response times, sometimes taking over a second to get a response, other times taking under 50ms.
Re: Barracuda Reputation Block List (BRBL) removal from the SA ruleset
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_2eval:check_rbl_sub('brbl', > '127.0.0.2') > metaRCVD_IN_BRBL__RCVD_IN_BRBL_2 && > !RCVD_IN_BRBL_LASTEXT > describeRCVD_IN_BRBLReceived is listed in Barracuda RBL > bb.barracudacentral.org > score RCVD_IN_BRBL1.2 > tflags RCVD_IN_BRBLnet > > header RCVD_IN_BRBL_LASTEXT > eval:check_rbl('brbl-lastexternal', > 'bb.barracudacentral.org') > describeRCVD_IN_BRBL_LASTEXTLast external is listed in > Barracuda > RBL bb.barracudacentral.org > score RCVD_IN_BRBL_LASTEXT2.2 > tflags RCVD_IN_BRBL_LASTEXTnet > > 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.
Re: Barracuda Reputation Block List (BRBL) removal from the SA ruleset
On 02/06/2018 10:38 AM, Alex wrote: Hi, On Tue, Feb 6, 2018 at 8:44 AM, David Joneswrote: 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_2eval:check_rbl_sub('brbl', '127.0.0.2') metaRCVD_IN_BRBL__RCVD_IN_BRBL_2 && !RCVD_IN_BRBL_LASTEXT describeRCVD_IN_BRBLReceived is listed in Barracuda RBL bb.barracudacentral.org score RCVD_IN_BRBL1.2 tflags RCVD_IN_BRBLnet header RCVD_IN_BRBL_LASTEXT eval:check_rbl('brbl-lastexternal', 'bb.barracudacentral.org') describeRCVD_IN_BRBL_LASTEXTLast external is listed in Barracuda RBL bb.barracudacentral.org score RCVD_IN_BRBL_LASTEXT2.2 tflags RCVD_IN_BRBL_LASTEXTnet 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. 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. 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. ifplugin Mail::SpamAssassin::Plugin::DNSEval header __RCVD_IN_LASHBACK eval:check_rbl('lashback', 'ubl.unsubscore.com.') describe __RCVD_IN_LASHBACK Received is listed in Lashback ubl.unsubscore.com tflags __RCVD_IN_LASHBACK net header __RCVD_IN_LASHBACK_2eval:check_rbl_sub('lashback', '127.0.0.2') metaRCVD_IN_LASHBACK__RCVD_IN_LASHBACK_2 && !RCVD_IN_LASHBACK_LASTEXT describeRCVD_IN_LASHBACKReceived is listed in Lashback ubl.unsubscore.com score RCVD_IN_LASHBACK2.2 tflags RCVD_IN_LASHBACKnet header RCVD_IN_LASHBACK_LASTEXT eval:check_rbl('lashback-lastexternal', 'ubl.unsubscore.com.') describe RCVD_IN_LASHBACK_LASTEXT Last external is listed in Lashback ubl.unsubscore.com score RCVD_IN_LASHBACK_LASTEXT4.2 tflags RCVD_IN_LASHBACK_LASTEXTnet endif -- David Jones
Re: Barracuda Reputation Block List (BRBL) removal from the SA ruleset
Hi, On Tue, Feb 6, 2018 at 8:44 AM, David Joneswrote: > 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_2eval:check_rbl_sub('brbl', >>> '127.0.0.2') >>> metaRCVD_IN_BRBL__RCVD_IN_BRBL_2 && !RCVD_IN_BRBL_LASTEXT >>> describeRCVD_IN_BRBLReceived is listed in Barracuda RBL >>> bb.barracudacentral.org >>> score RCVD_IN_BRBL1.2 >>> tflags RCVD_IN_BRBLnet >>> >>> header RCVD_IN_BRBL_LASTEXT eval:check_rbl('brbl-lastexternal', >>> 'bb.barracudacentral.org') >>> describeRCVD_IN_BRBL_LASTEXTLast external is listed in >>> Barracuda >>> RBL bb.barracudacentral.org >>> score RCVD_IN_BRBL_LASTEXT2.2 >>> tflags RCVD_IN_BRBL_LASTEXTnet >>> >>> 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?
Re: Barracuda Reputation Block List (BRBL) removal from the SA ruleset
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_2eval:check_rbl_sub('brbl', '127.0.0.2') metaRCVD_IN_BRBL__RCVD_IN_BRBL_2 && !RCVD_IN_BRBL_LASTEXT describeRCVD_IN_BRBLReceived is listed in Barracuda RBL bb.barracudacentral.org score RCVD_IN_BRBL1.2 tflags RCVD_IN_BRBLnet header RCVD_IN_BRBL_LASTEXT eval:check_rbl('brbl-lastexternal', 'bb.barracudacentral.org') describeRCVD_IN_BRBL_LASTEXTLast external is listed in Barracuda RBL bb.barracudacentral.org score RCVD_IN_BRBL_LASTEXT2.2 tflags RCVD_IN_BRBL_LASTEXTnet 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. -- David Jones
Re: Barracuda Reputation Block List (BRBL) removal from the SA ruleset
David Jones skrev den 2018-02-05 15:09: 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_2eval:check_rbl_sub('brbl', '127.0.0.2') metaRCVD_IN_BRBL__RCVD_IN_BRBL_2 && !RCVD_IN_BRBL_LASTEXT describeRCVD_IN_BRBLReceived is listed in Barracuda RBL bb.barracudacentral.org score RCVD_IN_BRBL1.2 tflags RCVD_IN_BRBLnet header RCVD_IN_BRBL_LASTEXT eval:check_rbl('brbl-lastexternal', 'bb.barracudacentral.org') describeRCVD_IN_BRBL_LASTEXTLast external is listed in Barracuda RBL bb.barracudacentral.org score RCVD_IN_BRBL_LASTEXT2.2 tflags RCVD_IN_BRBL_LASTEXTnet endif On 05.02.18 16:26, Benny Pedersen wrote: this rule makes 2 dns querys, waste of cpu performance, i would suggest to drop the lastextnal, this rule checks all untrusted IPs, while lastexternal uses only one (often the most important - IP that sent mail to your systems). also, because of caching, brbl-lastexternal result will be cached. b.barracudacentral.org uses ttl of 300, which should be cached during the mail processing. if you want to spare DNS queries, leave only lastexternal. so its only if ip is listed yes or no, 50% dns querys saved, and still same hits on listed ips, why do we need to help spammers ? network checks including DNS lookups help much in spam processing, after bayes they are second best mechanism to detect spam. NOT using them is helping spammers. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Atheism is a non-prophet organization.
Re: Barracuda Reputation Block List (BRBL) removal from the SA ruleset
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_2eval:check_rbl_sub('brbl', > '127.0.0.2') > metaRCVD_IN_BRBL__RCVD_IN_BRBL_2 && !RCVD_IN_BRBL_LASTEXT > describeRCVD_IN_BRBLReceived is listed in Barracuda RBL > bb.barracudacentral.org > score RCVD_IN_BRBL1.2 > tflags RCVD_IN_BRBLnet > > header RCVD_IN_BRBL_LASTEXT eval:check_rbl('brbl-lastexternal', > 'bb.barracudacentral.org') > describeRCVD_IN_BRBL_LASTEXTLast external is listed in Barracuda > RBL bb.barracudacentral.org > score RCVD_IN_BRBL_LASTEXT2.2 > tflags RCVD_IN_BRBL_LASTEXTnet > > 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...
Re: Barracuda Reputation Block List (BRBL) removal from the SA ruleset
On Mon, 05 Feb 2018 17:12:08 +0100 Benny Pedersen wrote: > Kevin A. McGrail skrev den 2018-02-05 16:53: > > > I don't think that will apply will it because it will be looking up > > something like 1.2.3.4.bb.barracuda.blah which isn't cached. > > the first qurry can make a qurry with very low ttl, so it would not > be cached, that means number 2 query still mkae dns query to that > zone :( SA sends its DNS requests out early in rapid succession. The chances are that the local DNS cache would see the second request as a duplicate of a pending look-up. In that case caching is not needed. > > Anyway, we're debating a rule that's removed :) > lastexternal is still a mistake imho :=) lastexternal is correct, that's what RCVD_IN_BRBL_LASTEXT does. Making use of deep checks on lists containing dynamic addresses is risky, and likely to vary a lot between different mail flows. David's rules are not appropriate as a general replacement for RCVD_IN_BRBL_LASTEXT IMO.
Re: Barracuda Reputation Block List (BRBL) removal from the SA ruleset
On 2/5/2018 11:32 AM, RW wrote: Just to clarify, there is no legal or moral obligation to do this, the 'bb' subdomain was created specifically so SA users wouldn't need to register. Anything you may read on the Barracuda site applies to the 'b' version. Barracuda has given no indication that anything has changed. I've been trying to reach Barracuda pretty doggedly about the issue for months about the issues with bb requiring registration hence the removal. If you have a contact, get in touch with them and we can relight the rule. I was hoping some discussion on list might get their attention. Regards, KAM
Re: Barracuda Reputation Block List (BRBL) removal from the SA ruleset
On Mon, 5 Feb 2018 08:09:55 -0600 David Jones wrote: > Heads up! This RBL has been removed from the core SA ruleset. In 36 > to 48 hours sa-update will remove the RCVD_IN_BRBL_LASTEXT rule after > it has gone through the masscheck and rule promotion process. > > Details can be found here: > > https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7417 > > To add this rule back manually, you should register here: > > http://barracudacentral.org/account/register Just to clarify, there is no legal or moral obligation to do this, the 'bb' subdomain was created specifically so SA users wouldn't need to register. Anything you may read on the Barracuda site applies to the 'b' version. Barracuda has given no indication that anything has changed. The issue is that some users have seen look-ups fail and attributed it to possible rate limiting on non-registered IP addresses. You should register if you use the 'b' list directly from an MTA. If you only run the 'bb' version from SA and use fixed IP addresses it *may* help with reliability if you register. If you run SA client side on a dynamic address there's no point in registering. > and add this to your local.cf: I would suggest people just copy the existing rule as it is. This list contains dynamic IP addresses so shouldn't be used for deep look-ups. > NOTE: recent masscheck processing shows RCVD_IN_BRBL_LASTEXT as the > most effective non-zero scoring rule to hit spam (43%) so it's > probably worth adding back to your local.cf on Wednesday or Thursday. If you don't rename the rule there's no need to wait. Note that once it's removed the scores for other rules will adjust to compensate for its absence, and this *may* lead to more FP's if it's left at its current score.
Re: Barracuda Reputation Block List (BRBL) removal from the SA ruleset
Kevin A. McGrail skrev den 2018-02-05 16:53: I don't think that will apply will it because it will be looking up something like 1.2.3.4.bb.barracuda.blah which isn't cached. the first qurry can make a qurry with very low ttl, so it would not be cached, that means number 2 query still mkae dns query to that zone :( Anyway, we're debating a rule that's removed :) lastexternal is still a mistake imho :=) gosh i hate bind9 not have minimal ttl, good thing is that low ttl strikes back to badly configured dns zones :=)
Re: Barracuda Reputation Block List (BRBL) removal from the SA ruleset
On 02/05/2018 09:44 AM, Reindl Harald wrote: Am 05.02.2018 um 16:36 schrieb David Jones: On 02/05/2018 09:26 AM, Benny Pedersen wrote: David Jones skrev den 2018-02-05 15:09: 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 this rule makes 2 dns querys, waste of cpu performance, i would suggest to drop the lastextnal, so its only if ip is listed yes or no, 50% dns querys saved, and still same hits on listed ips, why do we need to help spammers ? If you are running a local DNS cache like this list and the SA documention recommends, does this really matter? My MTA should have already queried this before SA does it so it should be in the local DNS cache and not require a full recursive lookup from the SA rule above 1.2 poitns just because the IP of the previous hop is listet is pure nonsense and it was even nosense as Barracuda Networks started with that bullshit called "deep header inspection" Barracuda and many other RBL's list here a ton of innocent IP's which are nothing else than the endusers range which never should tocu an inbound MX itself so what the hell is the point that you give me 1.2 points because i use as i should our MTA from my home-ip to send an ordianry mail? It can be a sign of a compromised account. I just saw a compromised account coming from Nigeria listed on BRBL through Office 365. Now that O365 is finally adding the "x-originating-ip" header, we can detect botnets sending via infected home computers. Legit emails should have other rules subtracting points so a 1.2 should not be a major factor in the score. My mail platform is scoring real spam greater than 18 and usually in the 20's. I could leave this rule out and be fine but most default SA instances would benefit from it. If they want to lower the scores, then make them 0.2 and 1.2 then and use them in meta rules. -- David Jones
Re: Barracuda Reputation Block List (BRBL) removal from the SA ruleset
On 2/5/2018 10:36 AM, David Jones wrote: If you are running a local DNS cache like this list and the SA documention recommends, does this really matter? My MTA should have already queried this before SA does it so it should be in the local DNS cache and not require a full recursive lookup from the SA rule above. I don't think that will apply will it because it will be looking up something like 1.2.3.4.bb.barracuda.blah which isn't cached. Anyway, we're debating a rule that's removed :) Regards, KAM
Re: Barracuda Reputation Block List (BRBL) removal from the SA ruleset
David Jones skrev den 2018-02-05 16:36: If you are running a local DNS cache like this list and the SA documention recommends, does this really matter? My MTA should have already queried this before SA does it so it should be in the local DNS cache and not require a full recursive lookup from the SA rule above. yes it matters with low ttl, non datafeeds have low ttl, so it does not cache much on dns servers, sadly, this can be avoided in spamassassin without 2 dns querys it have always just be low priotet since we all assume datafedds where is does not matter This shouldn't be the case with a local DNS cache with the /etc/resolv.conf pointed to 127.0.0.1 or SA dns_server pointed to 127.0.0.1. already done here can lastexternal be solved to only use one query ? as is i think spamassassin should be changed so it can if not already on top of that bb. is for spamassassin, while b. was for mta stage, so 200% more querys to non datafeeds :/ it should have being one dns zone
Re: Barracuda Reputation Block List (BRBL) removal from the SA ruleset
On 02/05/2018 09:26 AM, Benny Pedersen wrote: David Jones skrev den 2018-02-05 15:09: 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 this rule makes 2 dns querys, waste of cpu performance, i would suggest to drop the lastextnal, so its only if ip is listed yes or no, 50% dns querys saved, and still same hits on listed ips, why do we need to help spammers ? If you are running a local DNS cache like this list and the SA documention recommends, does this really matter? My MTA should have already queried this before SA does it so it should be in the local DNS cache and not require a full recursive lookup from the SA rule above. anyway i dont use it, above rule is only optimized for datafeeds, it will drain non datafeed clients into hell This shouldn't be the case with a local DNS cache with the /etc/resolv.conf pointed to 127.0.0.1 or SA dns_server pointed to 127.0.0.1. can lastexternal be solved to only use one query ? as is i think spamassassin should be changed so it can if not already -- David Jones
Re: Barracuda Reputation Block List (BRBL) removal from the SA ruleset
David Jones skrev den 2018-02-05 15:09: 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_2eval:check_rbl_sub('brbl', '127.0.0.2') metaRCVD_IN_BRBL__RCVD_IN_BRBL_2 && !RCVD_IN_BRBL_LASTEXT describeRCVD_IN_BRBLReceived is listed in Barracuda RBL bb.barracudacentral.org score RCVD_IN_BRBL1.2 tflags RCVD_IN_BRBLnet header RCVD_IN_BRBL_LASTEXT eval:check_rbl('brbl-lastexternal', 'bb.barracudacentral.org') describeRCVD_IN_BRBL_LASTEXTLast external is listed in Barracuda RBL bb.barracudacentral.org score RCVD_IN_BRBL_LASTEXT2.2 tflags RCVD_IN_BRBL_LASTEXTnet endif this rule makes 2 dns querys, waste of cpu performance, i would suggest to drop the lastextnal, so its only if ip is listed yes or no, 50% dns querys saved, and still same hits on listed ips, why do we need to help spammers ? anyway i dont use it, above rule is only optimized for datafeeds, it will drain non datafeed clients into hell can lastexternal be solved to only use one query ? as is i think spamassassin should be changed so it can if not already
Barracuda Reputation Block List (BRBL) removal from the SA ruleset
Heads up! This RBL has been removed from the core SA ruleset. In 36 to 48 hours sa-update will remove the RCVD_IN_BRBL_LASTEXT rule after it has gone through the masscheck and rule promotion process. Details can be found here: https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7417 To add this rule back manually, you should register here: http://barracudacentral.org/account/register and add this to your local.cf: 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_2eval:check_rbl_sub('brbl', '127.0.0.2') metaRCVD_IN_BRBL__RCVD_IN_BRBL_2 && !RCVD_IN_BRBL_LASTEXT describeRCVD_IN_BRBLReceived is listed in Barracuda RBL bb.barracudacentral.org score RCVD_IN_BRBL1.2 tflags RCVD_IN_BRBLnet header RCVD_IN_BRBL_LASTEXT eval:check_rbl('brbl-lastexternal', 'bb.barracudacentral.org') describeRCVD_IN_BRBL_LASTEXTLast external is listed in Barracuda RBL bb.barracudacentral.org score RCVD_IN_BRBL_LASTEXT2.2 tflags RCVD_IN_BRBL_LASTEXTnet endif NOTE: recent masscheck processing shows RCVD_IN_BRBL_LASTEXT as the most effective non-zero scoring rule to hit spam (43%) so it's probably worth adding back to your local.cf on Wednesday or Thursday. http://ruleqa.spamassassin.org/20180203-r1823022-n/RCVD_IN_BRBL_LASTEXT/detail -- David Jones