Re: queying fresh.fmb.la despite skip_rbl_checks
Maybe a tflag on the AskDNS to mark it as an RBL lookup? This doesn't exist currently Adjusting to "dns_query_restriction deny fmb.la" will avoid just this domain lookups Paul On Fri, 15 Jan 2021 at 13:09, RW wrote: > On Fri, 15 Jan 2021 09:43:42 +0100 > Dan Malm wrote: > > > I've just noticed that spamassassin queries > > .fresh.fmb.la despite me having set "skip_rbl_checks 1" > > ... > > > Am I missing something? > > That list is queried via AskDNS. > >
Re: queying fresh.fmb.la despite skip_rbl_checks
On Fri, 15 Jan 2021 09:43:42 +0100 Dan Malm wrote: > I've just noticed that spamassassin queries > .fresh.fmb.la despite me having set "skip_rbl_checks 1" > ... > Am I missing something? That list is queried via AskDNS.
queying fresh.fmb.la despite skip_rbl_checks
Hi, I've just noticed that spamassassin queries .fresh.fmb.la despite me having set "skip_rbl_checks 1" in my local.cf The only way I seem to be able to stop it from being queried is to set "dns_query_restriction deny la" This happens both on FreeBSD 12.2 SpamAssassin version 3.4.4 running on Perl version 5.32.0 and on Linux (Ubuntu 20.04.1) SpamAssassin version 3.4.4 running on Perl version 5.30.0 Am I missing something? Shouldn't fmb.la be affected by the skip_rbl_checks setting? And if not, are there other rbls I'm unknowingly querying that I should know of? -- BR/Mvh. Dan Malm, Systems Engineer, One.com
Re: **exact** info about "skip_rbl_checks" needed
David B Funk wrote: On Fri, 26 Jan 2007, Daryl C. W. O'Shea wrote: Some of my incoming mesasges involve messages forwarded to my server via a rule from accounts that some of my clients have on other ISPs mail servers. For such incoming messages, I have been creating a temporary copy of the message where all headers that were ADDED by either the other ISP and/or my server are removed so that the message is brought back to the state that it was in when originally sent by the original sender (just prior to the ISP's mail server received it). This way, SA can work with that the potential spammer actually sent, without any received headers added. But is that really necessary? Or would I get the same results if, under my configuration described above, I just left the extra added headers in there? To get the same functionality without stripping headers you'd have to add the forwarders' IPs to your trusted and internal networks config. Pardon my confusion, but wouldn't it be sufficient to just add them to the trusted networks list? (IE not adding them to internal too). If you haven't already defined internal_networks, yes, since internal_networks will default to whatever you use for trusted_networks. Having them in both trusted and internal networks is more similar to stripping the received headers than having them in trusted but not internal. IIUR, internal networks are for clients that will source messages, trusted is for MTAs that feed you. Am I missing something? I think you are. - for something to be internal it has to be trusted (you can't have an internal but not trusted relay) - relays that act as MXes need to be both trusted and internal - all relays between an MX and SA need to also be both trusted and internal Adding the forwarding situation described: - the MX for the account forwarding to the local account is acting as an MX for the final destination account (forwarding is messy) - all relays between an MX (the one for the account forwarding to the local account) and SA (thus all relays between the remote MX and your MX) need to be both trusted and internal On the submission side (not involved in the original question) it goes something like this: - if the MSA isn't an MX or internal relay between an MX and SA you want it to be trusted but not internal; otherwise it has to be both trusted and internal and you'd better have auth tokens in the received headers (or be using the POPAuth plugin) Daryl
Re: **exact** info about "skip_rbl_checks" needed
On Fri, 26 Jan 2007, Daryl C. W. O'Shea wrote:
> >
> > Some of my incoming mesasges involve messages forwarded to my server via a
> > rule from accounts that some of my clients have on other ISPs mail servers.
> > For such incoming messages, I have been creating a temporary copy of the
> > message where all headers that were ADDED by either the other ISP and/or my
> > server are removed so that the message is brought back to the state that it
> > was in when originally sent by the original sender (just prior to the ISP's
> > mail server received it). This way, SA can work with that the potential
> > spammer actually sent, without any received headers added.
> >
> > But is that really necessary? Or would I get the same results if, under my
> > configuration described above, I just left the extra added headers in there?
>
> To get the same functionality without stripping headers you'd have to
> add the forwarders' IPs to your trusted and internal networks config.
Pardon my confusion, but wouldn't it be sufficient to just add them to
the trusted networks list? (IE not adding them to internal too).
IIUR, internal networks are for clients that will source messages,
trusted is for MTAs that feed you. Am I missing something?
--
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: **exact** info about "skip_rbl_checks" needed
My question... why **exactly** can't webmail line wrap messages? :) Rob McEwen (PowerView Systems) wrote: 1st question: Some of my incoming mesasges involve messages forwarded to my server via a rule from accounts that some of my clients have on other ISPs mail servers. For such incoming messages, I have been creating a temporary copy of the message where all headers that were ADDED by either the other ISP and/or my server are removed so that the message is brought back to the state that it was in when originally sent by the original sender (just prior to the ISP's mail server received it). This way, SA can work with that the potential spammer actually sent, without any received headers added. But is that really necessary? Or would I get the same results if, under my configuration described above, I just left the extra added headers in there? To get the same functionality without stripping headers you'd have to add the forwarders' IPs to your trusted and internal networks config. (I'm concerned that, even with skip_rbl_checks turned off, there might still be SPF checking or other things going on which then might get messed up if I don't present the message in its "original" form. PLEASE... let me know if that is the case. This will only be about the 10th time that I've asked what other "network checks" happen besides Razor/DCC when skip_rbl_checks is set to true.) SPF checks aren't RBL checks, so skip_rbl_checks doesn't affect them. Enabling or disabling the SPF plugin and/or rules affects whether SPF checks are done. As for what other network checks are done; run a message through in debug mode and find out. Everything is logged in the debug output. This'll only be about the 2nd time I've suggested this, 8 more to go to catch up. :) 2nd question: Does SA have any problems working with a file that OTHER programs are currently accessing (in "read" mode)? Just like any other simultaneous file access, if the lock states are compatible you're OK. If there is some file in a lock state that isn't compatible with what SA wants to do SA will continue on after a short time, so there's no risk in SA hanging up. Daryl
**exact** info about "skip_rbl_checks" needed
BACKGROUND: First, I do NOT use SA for IP or URI based lookups as I do those in my own custom programmed spam filter. But I do desire to use SA for such things as Razor, SARE rules, ImageInfo, etc. Therefore, I have the following set up to prevent IP lookups: skip_rbl_checks 1 And other items are "commented out" to prevent such things as SURBL and URIBL lookups since I'm already doing those, too. Also, I also choose have bayes turned off. THAT IS THE BACKGROUND... HERE IS THE QUESTION: 1st question: Some of my incoming mesasges involve messages forwarded to my server via a rule from accounts that some of my clients have on other ISPs mail servers. For such incoming messages, I have been creating a temporary copy of the message where all headers that were ADDED by either the other ISP and/or my server are removed so that the message is brought back to the state that it was in when originally sent by the original sender (just prior to the ISP's mail server received it). This way, SA can work with that the potential spammer actually sent, without any received headers added. But is that really necessary? Or would I get the same results if, under my configuration described above, I just left the extra added headers in there? (I'm concerned that, even with skip_rbl_checks turned off, there might still be SPF checking or other things going on which then might get messed up if I don't present the message in its "original" form. PLEASE... let me know if that is the case. This will only be about the 10th time that I've asked what other "network checks" happen besides Razor/DCC when skip_rbl_checks is set to true.) 2nd question: Does SA have any problems working with a file that OTHER programs are currently accessing (in "read" mode)? Thanks! Rob McEwen PowerView Systems [EMAIL PROTECTED]
Re: Does skip_rbl_checks have influence on razor 2 and DCC?
Volker wrote: Hi, does anybody know if disabling "skip_rbl_checks" does stop razor 2 checks and DCC too even if razor2 and dcc are enabled in local.cf? Run spamassassin in debug mode and find out. Daryl
Does skip_rbl_checks have influence on razor 2 and DCC?
Hi, does anybody know if disabling "skip_rbl_checks" does stop razor 2 checks and DCC too even if razor2 and dcc are enabled in local.cf? Best regards Volker
Re: skip_rbl_checks
On Mon, Jun 26, 2006 at 01:45:14PM -0400, Rob McEwen (PowerView Systems) wrote: > I know that it turns of all "regular" RBL checks (where the IP address is > checked against a traditional RBL) Yes. > I'm fairly sure that it turns off SURBL & URIBL checks, right? No. The URIDNSBL plugin doesn't pay attention to the skip_rbl_checks option. > I'm fairly sure that it does NOT turn off DCC, Razor, Pyzor, etc, right? Correct. > But what else is effected?... is there a comprehensive list or a more > detailed explanation anywhere? I don't think there's a lot of documentation written for users out there about this (wiki maybe?), but in general it's any rbl checks which is what the docs say. (ie: any of the check_rbl* rules) The slightly more detailed version is that if you grep through the code for skip_rbl_checks, there are three functions in EvalTests which check the option value: check_rbl_backend This ends up getting called by check_rbl, check_rbl_txt, check_rbl_accreditor -- all of which are exclusively used in the rules files. check_rbl_sub Also known as check_rbl_results_for, used exclusively in the rules files. _check_rbl_addresses Called from check_rbl_from_host and check_rbl_envfrom, used exclusively in the rules files. I'll leave it as an exercise for the reader to convert the above information into a rule listing, but in short it's the DNSBL and DNSWL rules. :) -- Randomly Generated Tagline: "Software engineering is a race between engineers who try to create foolproof software and the universe which is trying to create bigger fools. So far, the universe is winning..." - Michael H. Warfield pgp0MQWXyqBVM.pgp Description: PGP signature
RE: skip_rbl_checks
RE: skip_rbl_checks Does anyone know **exactly** what "skip_rbl_checks = 1" turns off? I know that it turns of all "regular" RBL checks (where the IP address is checked against a traditional RBL) I'm fairly sure that it turns off SURBL & URIBL checks, right? I'm fairly sure that it does NOT turn off DCC, Razor, Pyzor, etc, right? But what else is effected?... is there a comprehensive list or a more detailed explanation anywhere? Thanks, Rob McEwen PowerView Systems [EMAIL PROTECTED]
