Re: writing own rbl rules
Am 29.08.2014 um 02:29 schrieb Karsten Bräckelmann: > On Fri, 2014-08-29 at 01:59 +0200, Reindl Harald wrote: > You can easily run RBL tests against IPs from within the local network > and treat them like any other sending SMTP client, by (a) excluding > them from the appropriate *_networks settings, and (b) define the RBL > test accordingly. If you want to query for the last-external, it has to > be the last external relay according to the configuration and the *how* was the only question *how* to define the rule to not care about last-external signature.asc Description: OpenPGP digital signature
Re: writing own rbl rules
On Fri, 2014-08-29 at 01:59 +0200, Reindl Harald wrote:
> Am 29.08.2014 um 01:51 schrieb Karsten Bräckelmann:
> > On Fri, 2014-08-29 at 01:06 +0200, Reindl Harald wrote:
> > > the question was just "how can i enforce RBL tests inside the own LAN"
> >
> > RBL tests cannot be enforced. Internal and trusted networks settings
> > need to be configured correctly to match the RBL test's scope, in your
> > case last-external.
> >
> > If there are trusted relays found in the Received headers, and the first
> > trusted one's connecting relay is external (not in the internal_networks
> > set), then an RBL test for last-external will be run.
> >
> > This is entirely unrelated to "own LAN" or "network range"
>
> that may all be true for blacklists and default RBL rules
>
> it is no longer true in case of 4 internal WHITELISTS which you
> want to use to LOWER scores to reduce false positives while
> otherwise bayes may hit - such traffic can also come from
> the internal network
There is absolutely no difference between black and whitelists. With the
only, obvious exception of the rule's score.
So, yes, it still is true in the case of (internal) whitelists.
Besides that, you are (still) confusing SA *_networks settings with the
local network topology. They are loosely related, but don't have to
match.
You can easily run RBL tests against IPs from within the local network
and treat them like any other sending SMTP client, by (a) excluding
them from the appropriate *_networks settings, and (b) define the RBL
test accordingly. If you want to query for the last-external, it has to
be the last external relay according to the configuration.
BTW, unless the set of IPs to whitelist is permanently changing, it is
much easier to write a negative score rule based on the X-Spam-Relays-*
pseudo-headers. This also has the benefit of being highly flexible, not
depend on trust borders and allow to maintain internal_networks matching
the LAN topology.
--
char *t="\10pse\0r\0dtu\0.@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4";
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;i>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
Re: writing own rbl rules
Am 29.08.2014 um 01:51 schrieb Karsten Bräckelmann: > On Fri, 2014-08-29 at 01:06 +0200, Reindl Harald wrote: >> the question was just "how can i enforce RBL tests inside the own LAN" > >> the question was just "how can i enforce RBL tests inside the own LAN" > >> the question was just "how can i enforce RBL tests inside the own LAN" > > RBL tests cannot be enforced. Internal and trusted networks settings > need to be configured correctly to match the RBL test's scope, in your > case last-external. > > If there are trusted relays found in the Received headers, and the first > trusted one's connecting relay is external (not in the internal_networks > set), then an RBL test for last-external will be run. > > This is entirely unrelated to "own LAN" or "network range" that may all be true for blacklists and default RBL rules it is no longer true in case of 4 internal WHITELISTS which you want to use to LOWER scores to reduce false positives while otherwise bayes may hit - such traffic can also come from the internal network in case of having postscreen and scoring in front of SA it is even a valid usecase to *completly* skip SA's using of blacklists and have 4 different DNSWL in the internal network with different trust-levels and hence different negative scores frankly it is somehow pervert that you can send a specific mailbody from outside and get a DNSWL negative score leading to accpet the message correctly and send the exactly same message from the own LAN and get it rejected by bayse filters that's also a lot of more trustable then sender whitelisting signature.asc Description: OpenPGP digital signature
Re: writing own rbl rules
On Fri, 2014-08-29 at 01:06 +0200, Reindl Harald wrote:
> the question was just "how can i enforce RBL tests inside the own LAN"
> the question was just "how can i enforce RBL tests inside the own LAN"
> the question was just "how can i enforce RBL tests inside the own LAN"
RBL tests cannot be enforced. Internal and trusted networks settings
need to be configured correctly to match the RBL test's scope, in your
case last-external.
If there are trusted relays found in the Received headers, and the first
trusted one's connecting relay is external (not in the internal_networks
set), then an RBL test for last-external will be run.
This is entirely unrelated to "own LAN" or "network range".
> >>> Received headers before that simply CANNOT be trusted. There is no way
> >>> to guarantee the host they claim to have received the message from is
> >>> legit
> >>
> >> in case running postfix with SA as milter *there are no* Received
> >> headers *before* because there is nobody before
> >
> > There almost always is at least one Received header before, the sender's
> > outgoing SMTP server
>
> *no no no and no again*
>
> there is no Received header before because a botnet zombie don't use
> a outgoing SMTP server
I said "almost always", with direct-to-MX delivery being the obvious
exception. Possible with botnet spam, yes, but too easy to detect. Thus,
botnet zombies frequently forge Received headers.
(Besides, in your environment SA won't see much botnet spam anyway.
Spamhaus PBL as first level of defense in your Postfix configuration
will reject most of them. But that's not the point here.)
--
char *t="\10pse\0r\0dtu\0.@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4";
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;i>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
Re: writing own rbl rules
Am 29.08.2014 um 00:57 schrieb Karsten Bräckelmann: >> the simple answer to my question would have been "no, in no case SA does >> any RBL check if the client is from the same network range and there is >> no way to change that temporary even for development" [...] > > That would have been simpler indeed, but that also would have been wrong no, it would have been correct for the statet environment instead "if you don't follow CLI debugging good luck" while CLI debugging did not make any sense in the context >> if there is no hop before and hence no received headers before >> there is still a known IP - the one and only and in that case >> the currently connection client - there is no reason not fire >> a DNSBL/DNSWL against that IP > > SA is not the SMTP server, it has no knowledge of the connection's > remote IP. SA depends on the Received headers added by the internal > network's SMTP server (or its milter) to get that information. and that is the IP of the physical connecting client the question was just "how can i enforce RBL tests inside the own LAN" >>> Besides: SA is not an SMTP. It does not add the Received header. And it >>> absolutely has to inspect headers, whether you like that or not. That is >>> how SA determines exactly that last, trustworthy, "physical" IP. And for >>> that, trusted and internal networks need be correct, so by extension >>> external networks also are correct. >> >> and the machine SA is running on receiving the message adds that >> header which is in case of direct testing the one and only and >> so trustable > > Your configuration stated that machine is not trustable. *because* it did not work as it was trustable as the complete subnet *after* that i tried to "untrust" the complete own subnet it still did not work the question was just "how can i enforce RBL tests inside the own LAN" >>> In particular, your MX, your first internal relay, absolutely MUST be >>> trusted by SA. That is the SMTP relay identifying the sending host, >>> complete with IP and rDNS. >> >> again: the machine running SA *is the MX* > > Correct (even though it is irrelevant whether it is or not). So don't > configure SA to not trust that machine, and include at the very least > that IP in your trusted_networks. > > Your configuration stated that machine is not trustable. *after* it did also not work as it was trustable the question was just "how can i enforce RBL tests inside the own LAN" >>> Received headers before that simply CANNOT be trusted. There is no way >>> to guarantee the host they claim to have received the message from is >>> legit >> >> in case running postfix with SA as milter *there are no* Received >> headers *before* because there is nobody before > > There almost always is at least one Received header before, the sender's > outgoing SMTP server *no no no and no again* there is no Received header before because a botnet zombie don't use a outgoing SMTP server signature.asc Description: OpenPGP digital signature
Re: writing own rbl rules
On Fri, 2014-08-29 at 00:22 +0200, Reindl Harald wrote:
> the simple answer to my question would have been "no, in no case SA does
> any RBL check if the client is from the same network range and there is
> no way to change that temporary even for development" [...]
That would have been simpler indeed, but that also would have been
wrong.
> if there is no hop before and hence no received headers before
> there is still a known IP - the one and only and in that case
> the currently connection client - there is no reason not fire
> a DNSBL/DNSWL against that IP
SA is not the SMTP server, it has no knowledge of the connection's
remote IP. SA depends on the Received headers added by the internal
network's SMTP server (or its milter) to get that information.
> > Besides: SA is not an SMTP. It does not add the Received header. And it
> > absolutely has to inspect headers, whether you like that or not. That is
> > how SA determines exactly that last, trustworthy, "physical" IP. And for
> > that, trusted and internal networks need be correct, so by extension
> > external networks also are correct.
>
> and the machine SA is running on receiving the message adds that
> header which is in case of direct testing the one and only and
> so trustable
Your configuration stated that machine is not trustable.
> > In particular, your MX, your first internal relay, absolutely MUST be
> > trusted by SA. That is the SMTP relay identifying the sending host,
> > complete with IP and rDNS.
>
> again: the machine running SA *is the MX*
Correct (even though it is irrelevant whether it is or not). So don't
configure SA to not trust that machine, and include at the very least
that IP in your trusted_networks.
Your configuration stated that machine is not trustable.
> > Received headers before that simply CANNOT be trusted. There is no way
> > to guarantee the host they claim to have received the message from is
> > legit
>
> in case running postfix with SA as milter *there are no* Received
> headers *before* because there is nobody before
There almost always is at least one Received header before, the sender's
outgoing SMTP server.
--
char *t="\10pse\0r\0dtu\0.@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4";
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;i>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
Re: writing own rbl rules
besides that the setup is now in production Am 27.08.2014 um 03:48 schrieb Karsten Bräckelmann: > Again: Craft your samples to match real-life (production) environment. > Do not configure or try to fake an environment that will not match > production later. It won't work. > > You want to configure SA. So configure SA. Correctly. finally yes, not at development and testing that is what testing is for: * no access from outside * try to set trust on single IP's lacking different ranges > If you insist on not following that advice, please refrain from further > postings to this list. the simple answer to my question would have been "no, in no case SA does any RBL check if the client is from the same network range and there is no way to change that temporary even for development" instead start debug sessions with CLI tools while i already statet that i found out the RBL's are check if the connection comes from a foreign network that behavior still is a bug, not in production but it is a bug if there is no hop before and hence no received headers before there is still a known IP - the one and only and in that case the currently connection client - there is no reason not fire a DNSBL/DNSWL against that IP >> the intention to berak it was to behave like it is external >> and just check the RBL behavior > > Read my previous post again, carefully. If you define everything to be > external, there is no *last* external SA can trust. if there is only *one* received header it's from the MTA on which SA is running >> well, there will never be internal relays, just a inbound-only MX > > That IS an internal relay. Your MX must be in your internal_networks, > and it is by the very definition of MX an SMTP relay. the machine SA is running on *is the MX itself* > Besides: SA is not an SMTP. It does not add the Received header. And it > absolutely has to inspect headers, whether you like that or not. That is > how SA determines exactly that last, trustworthy, "physical" IP. And for > that, trusted and internal networks need be correct, so by extension > external networks also are correct. and the machine SA is running on receiving the message adds that header which is in case of direct testing the one and only and so trustable > In particular, your MX, your first internal relay, absolutely MUST be > trusted by SA. That is the SMTP relay identifying the sending host, > complete with IP and rDNS. again: the machine running SA *is the MX* > Received headers before that simply CANNOT be trusted. There is no way > to guarantee the host they claim to have received the message from is > legit in case running postfix with SA as milter *there are no* Received headers *before* because there is nobody before signature.asc Description: OpenPGP digital signature
Re: writing own rbl rules
On Wed, 2014-08-27 at 03:01 +0200, Reindl Harald wrote:
> > If it's internal, it's internal. There is a reason you are setting up
> > lastexternal DNSxL rules.
>
> the intention is to handle the internal IP like it would be external
Again: Craft your samples to match real-life (production) environment.
Do not configure or try to fake an environment that will not match
production later. It won't work.
You want to configure SA. So configure SA. Correctly.
If you insist on not following that advice, please refrain from further
postings to this list.
> >> Aug 27 00:59:29.249 [30833] dbg: metadata: X-Spam-Relays-Untrusted: [
> >> ip=10.0.0.19 rdns=mail-gw.thelounge.net
> >> helo=mail-gw.thelounge.net by=mail.thelounge.net ident= envfrom= intl=0
> >> id=3hjPzJ6TWVz23 auth= msa=0 ] [
> >> ip=10.0.0.6 rdns=arrakis.thelounge.net helo=arrakis.thelounge.net
> >> by=mail-gw.thelounge.net ident= envfrom= intl=0
> >> id=3hjPzJ2tkPz1w auth= msa=0 ]
> >
> > There is no X-Spam-Relays-Trusted metadata in your grep for "dns", which
> > means there is absolutely no trusted relay. Given those relays are in
> > the 10/8 class A network and you deliberately breaking trusted_networks
> > in a previous post, that seems about right...
>
> the intention to berak it was to behave like it is external
> and just check the RBL behavior
Read my previous post again, carefully. If you define everything to be
external, there is no *last* external SA can trust.
> > Anyway, there are no "dbg: dns: IPs found:" and "dbg: dns: launching"
> > lines, so this clearly shows the RBLs are NOT queried.
>
> that's my problem :-)
So you know how to fix it. Configure *_networks in SA correctly, and
send a message from an external host.
> > No activity with your custom RBL either. But well, how would you expect
> > SA to query *last* external, given you deliberately told SA there are no
> > internal relays...
>
> well, there will never be internal relays, just a inbound-only MX
That IS an internal relay. Your MX must be in your internal_networks,
and it is by the very definition of MX an SMTP relay.
> > All external. No internal, no last external aka "hop before first
> > internal" either.
>
> i want that RBL checks in general only for the *phyiscal* IP
> with no header inspections - 90% of inflow will be finally
> filtered out by postcsreen anyways
You need an internal, trusted relay to get that IP you desire. That
relay is what generates the Received header with precisely that IP.
Besides: SA is not an SMTP. It does not add the Received header. And it
absolutely has to inspect headers, whether you like that or not. That is
how SA determines exactly that last, trustworthy, "physical" IP. And for
that, trusted and internal networks need be correct, so by extension
external networks also are correct.
> > First of all, do read and understand the (trusted|internal)_networks
> > options in the M::SA::Conf [1] docs, section Network Test Options.
> >
> > Then remove the current bad *_networks options in your conf. If you
> > don't fully understand those docs, keep it at that, default. If you do
> > understand and see an actual need to manually set them, do so, but do so
> > *correctly*.
>
> the intention is no trust / untrust at all and handle any IP
> with it's phyiscal connection
Do read the docs I linked to.
You are totally misunderstanding trust. It is not about what you trust,
or don't. It is about which Received headers SA can trust to be correct.
In particular, your MX, your first internal relay, absolutely MUST be
trusted by SA. That is the SMTP relay identifying the sending host,
complete with IP and rDNS.
Received headers before that simply CANNOT be trusted. There is no way
to guarantee the host they claim to have received the message from is
legit.
> > [1] http://spamassassin.apache.org/doc/Mail_SpamAssassin_Conf.html
>
> thanks!
In general, I stand to what I wrote in the previous post. And I strongly
suggest you follow that advice.
The approach you tried and defended with claws in this already lengthy
thread will not work and is bound to fail. Stop arguing, and start
setting up a serious test environment and correct SA options.
--
char *t="\10pse\0r\0dtu\0.@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4";
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;i>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
Re: writing own rbl rules
Am 27.08.2014 um 02:24 schrieb Karsten Bräckelmann: > On Wed, 2014-08-27 at 01:08 +0200, Reindl Harald wrote: >> below the stdout/sterr of following script filtered for "dns" >> so the lists are asked, but the question remains why that >> don't happen from a IP in the same network > > Nope, no RBL queries. See below. yes, and that makes it hard to simulate things just in the internal network by add/remove hosts to own DNSBL/DNSWL lists >> in the meantime there are a lot of "cust-lastexternal" >> generated from a web-interface including the 4 below and >> the local network range is listed on them, hence why i >> want them used unconidtionally and not only with foreign IP's > > If it's internal, it's internal. There is a reason you are setting up > lastexternal DNSxL rules. the intention is to handle the internal IP like it would be external > Do not invalidate SA *_networks configuration in an attempt to adjust it > to poorly, non real-live generated samples. Generate a proper sample > instead, either by actually sending mail from external IPs, or if need > be by manually editing the MX Received header, forging an external > source (do pay attention to detail). it's about simulate behavior by develop admin backends and intergate existing tools > Besides, there is no point in whitelisting your own LAN IPs. Those > should simply hit ALL_TRUSTED, or just not be filtered in the first > place. not finally but at development >> /usr/bin/spamassassin -D < /var/lib/spamass-milter/spam-example.eml > >> [sa-milt@mail-gw:~]$ cat debug.txt | grep -i dns > >> Aug 27 00:59:29.249 [30833] dbg: metadata: X-Spam-Relays-Untrusted: [ >> ip=10.0.0.19 rdns=mail-gw.thelounge.net >> helo=mail-gw.thelounge.net by=mail.thelounge.net ident= envfrom= intl=0 >> id=3hjPzJ6TWVz23 auth= msa=0 ] [ >> ip=10.0.0.6 rdns=arrakis.thelounge.net helo=arrakis.thelounge.net >> by=mail-gw.thelounge.net ident= envfrom= intl=0 >> id=3hjPzJ2tkPz1w auth= msa=0 ] > > There is no X-Spam-Relays-Trusted metadata in your grep for "dns", which > means there is absolutely no trusted relay. Given those relays are in > the 10/8 class A network and you deliberately breaking trusted_networks > in a previous post, that seems about right... the intention to berak it was to behave like it is external and just check the RBL behavior >> Aug 27 00:59:29.249 [30833] dbg: metadata: X-Spam-Relays-External: [ >> ip=10.0.0.19 rdns=mail-gw.thelounge.net >> helo=mail-gw.thelounge.net by=mail.thelounge.net ident= envfrom= intl=0 >> id=3hjPzJ6TWVz23 auth= msa=0 ] [ >> ip=10.0.0.6 rdns=arrakis.thelounge.net helo=arrakis.thelounge.net >> by=mail-gw.thelounge.net ident= envfrom= intl=0 >> id=3hjPzJ2tkPz1w auth= msa=0 ] > > Same issue with X-Spam-Relays-Internal not showing up in the grep, thus > being completely empty. Unless you specified internal_networks manually, > it is set to trusted_networks. Thus equally invalid. for testing in the own network >> Aug 27 00:59:29.254 [30833] dbg: dns: checking RBL bl.spameatingmonkey.net., >> set cust12-lastexternal >> Aug 27 00:59:29.254 [30833] dbg: dns: checking RBL spam.dnsbl.sorbs.net., >> set cust15-lastexternal >> Aug 27 00:59:29.254 [30833] dbg: dns: checking RBL psbl.surriel.com., set >> cust14-lastexternal > > All those third-party RBLs with your "cust" sets are extremely fishy. there is a web-interface to enbale/disbale them per click and have them at the same time enabled for postscreen weighting while adjust positive/negative scoring for all enabled RBL's in the interface yet at development > Anyway, there are no "dbg: dns: IPs found:" and "dbg: dns: launching" > lines, so this clearly shows the RBLs are NOT queried. that's my problem :-) >> Aug 27 00:59:29.254 [30833] dbg: dns: checking RBL dnswl-low.thelounge.net., >> set cust16-lastexternal > > No activity with your custom RBL either. But well, how would you expect > SA to query *last* external, given you deliberately told SA there are no > internal relays... well, there will never be internal relays, just a inbound-only MX > All external. No internal, no last external aka "hop before first > internal" either. i want that RBL checks in general only for the *phyiscal* IP with no header inspections - 90% of inflow will be finally filtered out by postcsreen anyways > First of all, do read and understand the (trusted|internal)_networks > options in the M::SA::Conf [1] docs, section Network Test Options. > > Then remove the current bad *_networks options in your conf. If you > don't fully understand those docs, keep it at that, default. If you do > understand and see an actual need to manually set them, do so, but do so > *correctly*. the intention is no trust / untrust at all and handle any IP with it's phyiscal connection > Hints on gathering relevant information from the debug output: > > Don't just grep for generic "dns", but check specifics by grepping for > X-Spam-Relays and (trusted|internal)_networks. Better yet, don't grep > b
Re: writing own rbl rules
On Wed, 2014-08-27 at 01:08 +0200, Reindl Harald wrote:
> below the stdout/sterr of following script filtered for "dns"
> so the lists are asked, but the question remains why that
> don't happen from a IP in the same network
Nope, no RBL queries. See below.
> in the meantime there are a lot of "cust-lastexternal"
> generated from a web-interface including the 4 below and
> the local network range is listed on them, hence why i
> want them used unconidtionally and not only with foreign IP's
If it's internal, it's internal. There is a reason you are setting up
lastexternal DNSxL rules.
Do not invalidate SA *_networks configuration in an attempt to adjust it
to poorly, non real-live generated samples. Generate a proper sample
instead, either by actually sending mail from external IPs, or if need
be by manually editing the MX Received header, forging an external
source (do pay attention to detail).
Besides, there is no point in whitelisting your own LAN IPs. Those
should simply hit ALL_TRUSTED, or just not be filtered in the first
place.
> /usr/bin/spamassassin -D < /var/lib/spamass-milter/spam-example.eml
> [sa-milt@mail-gw:~]$ cat debug.txt | grep -i dns
> Aug 27 00:59:29.249 [30833] dbg: metadata: X-Spam-Relays-Untrusted: [
> ip=10.0.0.19 rdns=mail-gw.thelounge.net
> helo=mail-gw.thelounge.net by=mail.thelounge.net ident= envfrom= intl=0
> id=3hjPzJ6TWVz23 auth= msa=0 ] [
> ip=10.0.0.6 rdns=arrakis.thelounge.net helo=arrakis.thelounge.net
> by=mail-gw.thelounge.net ident= envfrom= intl=0
> id=3hjPzJ2tkPz1w auth= msa=0 ]
There is no X-Spam-Relays-Trusted metadata in your grep for "dns", which
means there is absolutely no trusted relay. Given those relays are in
the 10/8 class A network and you deliberately breaking trusted_networks
in a previous post, that seems about right...
> Aug 27 00:59:29.249 [30833] dbg: metadata: X-Spam-Relays-External: [
> ip=10.0.0.19 rdns=mail-gw.thelounge.net
> helo=mail-gw.thelounge.net by=mail.thelounge.net ident= envfrom= intl=0
> id=3hjPzJ6TWVz23 auth= msa=0 ] [
> ip=10.0.0.6 rdns=arrakis.thelounge.net helo=arrakis.thelounge.net
> by=mail-gw.thelounge.net ident= envfrom= intl=0
> id=3hjPzJ2tkPz1w auth= msa=0 ]
Same issue with X-Spam-Relays-Internal not showing up in the grep, thus
being completely empty. Unless you specified internal_networks manually,
it is set to trusted_networks. Thus equally invalid.
> Aug 27 00:59:29.254 [30833] dbg: dns: checking RBL bl.spameatingmonkey.net.,
> set cust12-lastexternal
> Aug 27 00:59:29.254 [30833] dbg: dns: checking RBL spam.dnsbl.sorbs.net., set
> cust15-lastexternal
> Aug 27 00:59:29.254 [30833] dbg: dns: checking RBL psbl.surriel.com., set
> cust14-lastexternal
All those third-party RBLs with your "cust" sets are extremely fishy.
Anyway, there are no "dbg: dns: IPs found:" and "dbg: dns: launching"
lines, so this clearly shows the RBLs are NOT queried.
> Aug 27 00:59:29.254 [30833] dbg: dns: checking RBL dnswl-low.thelounge.net.,
> set cust16-lastexternal
No activity with your custom RBL either. But well, how would you expect
SA to query *last* external, given you deliberately told SA there are no
internal relays...
All external. No internal, no last external aka "hop before first
internal" either.
First of all, do read and understand the (trusted|internal)_networks
options in the M::SA::Conf [1] docs, section Network Test Options.
Then remove the current bad *_networks options in your conf. If you
don't fully understand those docs, keep it at that, default. If you do
understand and see an actual need to manually set them, do so, but do so
*correctly*.
Hints on gathering relevant information from the debug output:
Don't just grep for generic "dns", but check specifics by grepping for
X-Spam-Relays and (trusted|internal)_networks. Better yet, don't grep
but search the debug output interactively, and read nearby / related
info.
While debugging, actually reading, searching for terms or at least
glimpsing the entire debug output is good advice anyway.
[1] http://spamassassin.apache.org/doc/Mail_SpamAssassin_Conf.html
--
char *t="\10pse\0r\0dtu\0.@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4";
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;i>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
Re: writing own rbl rules
Am 26.08.2014 um 22:23 schrieb Matthias Leisi:
> On Tue, Aug 26, 2014 at 9:25 PM, Reindl Harald wrote:
>
>>> spamc -your_normal_spamc_options >
>> are we really talking about the same?
>> that won't involve the network
>
> You need a full message, include any Received: etc headers, as it
> would appear on your MTA when it would pass it on to spamc (or
> whatever you use to call SpamAssassin).
thanks!
below the stdout/sterr of following script filtered for "dns"
so the lists are asked, but the question remains why that
don't happen from a IP in the same network
in the meantime there are a lot of "cust-lastexternal"
generated from a web-interface including the 4 below and
the local network range is listed on them, hence why i
want them used unconidtionally and not only with foreign IP's
header CUST_DNSWL_1
eval:check_rbl('cust16-lastexternal','dnswl-low.thelounge.net.')
describe CUST_DNSWL_1 Custom DNSBL/DNSWL
scoreCUST_DNSWL_1 -0.0005
header CUST_DNSWL_6
eval:check_rbl('cust21-lastexternal','dnswl-medium.thelounge.net.')
describe CUST_DNSWL_6 Custom DNSBL/DNSWL
scoreCUST_DNSWL_6 -0.5
header CUST_DNSWL_7
eval:check_rbl('cust22-lastexternal','dnswl-high.thelounge.net.')
describe CUST_DNSWL_7 Custom DNSBL/DNSWL
scoreCUST_DNSWL_7 -2.5
header CUST_DNSWL_8
eval:check_rbl('cust23-lastexternal','dnswl.thelounge.net.')
describe CUST_DNSWL_8 Custom DNSBL/DNSWL
scoreCUST_DNSWL_8 -4.5
__
[sa-milt@mail-gw:~]$ cat ./spam-example.sh
#!/usr/bin/bash
export LANG=en_GB.UTF-8
/usr/bin/spamc -s 1048576 --port=10027 --full <
/var/lib/spamass-milter/spam-example.eml
/usr/bin/spamassassin -D < /var/lib/spamass-milter/spam-example.eml
__
[sa-milt@mail-gw:~]$ cat debug.txt | grep -i dns
Aug 27 00:59:28.380 [30833] dbg: plugin: loading
Mail::SpamAssassin::Plugin::URIDNSBL from @INC
Aug 27 00:59:28.437 [30833] dbg: plugin: loading
Mail::SpamAssassin::Plugin::DNSEval from @INC
Aug 27 00:59:28.461 [30833] dbg: plugin: loading
Mail::SpamAssassin::Plugin::AskDNS from @INC
Aug 27 00:59:28.503 [30833] dbg: config: fixed relative path:
/var/lib/spamassassin/3.004000/updates_spamassassin_org/20_dnsbl_tests.cf
Aug 27 00:59:28.503 [30833] dbg: config: using
"/var/lib/spamassassin/3.004000/updates_spamassassin_org/20_dnsbl_tests.cf" for
included file
Aug 27 00:59:28.503 [30833] dbg: config: read file
/var/lib/spamassassin/3.004000/updates_spamassassin_org/20_dnsbl_tests.cf
Aug 27 00:59:28.515 [30833] dbg: config: fixed relative path:
/var/lib/spamassassin/3.004000/updates_spamassassin_org/20_dynrdns.cf
Aug 27 00:59:28.515 [30833] dbg: config: using
"/var/lib/spamassassin/3.004000/updates_spamassassin_org/20_dynrdns.cf" for
included file
Aug 27 00:59:28.515 [30833] dbg: config: read file
/var/lib/spamassassin/3.004000/updates_spamassassin_org/20_dynrdns.cf
Aug 27 00:59:29.244 [30833] dbg: dns: socket module IO::Socket::IP is
available, but no host support for IPv6
Aug 27 00:59:29.244 [30833] dbg: dns: EDNS, UDP payload size 4096
Aug 27 00:59:29.245 [30833] dbg: dns: servers obtained from Net::DNS :
[127.0.0.1]:53
Aug 27 00:59:29.245 [30833] dbg: dns: nameservers set to 127.0.0.1
Aug 27 00:59:29.245 [30833] dbg: dns: using socket module: IO::Socket::IP,
forced IPv4
Aug 27 00:59:29.245 [30833] dbg: dns: is Net::DNS::Resolver available? yes
Aug 27 00:59:29.245 [30833] dbg: dns: Net::DNS version: 0.78
Aug 27 00:59:29.246 [30833] dbg: plugin:
Mail::SpamAssassin::Plugin::DNSEval=HASH(0x2e58070) implements
'check_start', priority 0
Aug 27 00:59:29.248 [30833] dbg: received-header: parsed as [ ip=10.0.0.19
rdns=mail-gw.thelounge.net
helo=mail-gw.thelounge.net by=mail.thelounge.net ident= envfrom= intl=0
id=3hjPzJ6TWVz23 auth= msa=0 ]
Aug 27 00:59:29.249 [30833] dbg: received-header: parsed as [ ip=10.0.0.6
rdns=arrakis.thelounge.net
helo=arrakis.thelounge.net by=mail-gw.thelounge.net ident= envfrom= intl=0
id=3hjPzJ2tkPz1w auth= msa=0 ]
Aug 27 00:59:29.249 [30833] dbg: metadata: X-Spam-Relays-Untrusted: [
ip=10.0.0.19 rdns=mail-gw.thelounge.net
helo=mail-gw.thelounge.net by=mail.thelounge.net ident= envfrom= intl=0
id=3hjPzJ6TWVz23 auth= msa=0 ] [
ip=10.0.0.6 rdns=arrakis.thelounge.net helo=arrakis.thelounge.net
by=mail-gw.thelounge.net ident= envfrom= intl=0
id=3hjPzJ2tkPz1w auth= msa=0 ]
Aug 27 00:59:29.249 [30833] dbg: metadata: X-Spam-Relays-External: [
ip=10.0.0.19 rdns=mail-gw.thelounge.net
helo=mail-gw.thelounge.net by=mail.thelounge.net ident= envfrom= intl=0
id=3hjPzJ6TWVz23 auth= msa=0 ] [
ip=10.0.0.6 rdns=arrakis.thelounge.net helo=arrakis.thelounge.net
by=mail-gw.thelounge.net ident= envfrom= intl=0
id=3hjPzJ2tkPz1w auth= msa=0 ]
Aug 27 00:59:29.249 [30833] dbg: plugin:
Mail::SpamAssassin::Plugin::AskDNS=HASH(0x30f8e80) implements
'extract_metadata', priority 0
Aug 27 00:59:29.249 [30833] dbg: dns: clear_resolver
Aug 27 00:59:29.250 [30833] dbg:
Re: writing own rbl rules
On Tue, Aug 26, 2014 at 9:25 PM, Reindl Harald wrote: >> spamc -your_normal_spamc_options > are we really talking about the same? > that won't involve the network You need a full message, include any Received: etc headers, as it would appear on your MTA when it would pass it on to spamc (or whatever you use to call SpamAssassin). -- Matthias
Re: writing own rbl rules
On Tue, 2014-08-26 at 21:25 +0200, Reindl Harald wrote: > Am 26.08.2014 um 21:08 schrieb Martin Gregorie: > > Under the same directory as spamass-milter run: > > > > spamc -your_normal_spamc_options > are we really talking about the same? > that won't involve the network > Of course it will. spamc will send the message to your daemonised copy of spamd. Or you can switch to the same used as spamd runs under and run spamassassin -usual_commandline_parameters -D debug options
Re: writing own rbl rules
Am 26.08.2014 um 21:08 schrieb Martin Gregorie: > On Tue, 2014-08-26 at 20:08 +0200, Reindl Harald wrote: >> Am 26.08.2014 um 18:11 schrieb Axb: >>> On 08/26/2014 05:42 PM, Reindl Harald wrote: they are *not* i sepecially added the following lines to prevent the automatic adding to "trusted_networks" since the IP range is outside clear_trusted_networks trusted_networks 192.168.168.0/24 there was no trust at all in the headers and no hint why the DNSWL was skipped at all >>> >>> comment out >>> >>> #tflags RCVD_IN_RP_TLDNS1 net >>> >>> run that msg against spamassassin -D dns >>> see what it spits out >> >> sorry, no idea what you mean with "run that message against" >> > Under the same directory as spamass-milter run: > > spamc -your_normal_spamc_options signature.asc Description: OpenPGP digital signature
Re: writing own rbl rules
Le 26/08/2014 21:03, Reindl Harald a écrit : i just don't know how to do that with the setup and mailflow by just start "spamassassin -D dns" which runs the process but how to get the mail there? You need a copy of the message as a text file on your SA machine, then you simply run, from the command line, spamassassin -D debugoptions < message.txt and then look at the output on stderr. It's the only realistic way of running tests repeatedly on the same message, changing whatever configuration you need as you go. -- John
Re: writing own rbl rules
On Tue, 2014-08-26 at 20:08 +0200, Reindl Harald wrote: > > Am 26.08.2014 um 18:11 schrieb Axb: > > On 08/26/2014 05:42 PM, Reindl Harald wrote: > >> they are *not* i sepecially added the following lines > >> to prevent the automatic adding to "trusted_networks" > >> since the IP range is outside > >> > >> clear_trusted_networks > >> trusted_networks 192.168.168.0/24 > >> > >> there was no trust at all in the headers and no > >> hint why the DNSWL was skipped at all > >> > >> ADVANCE_FEE_4_NEW > >> ADVANCE_FEE_4_NEW_MONEY > >> ADVANCE_FEE_5_NEW > >> ADVANCE_FEE_5_NEW_MONEY > >> BAYES_99 > >> BAYES_999 > >> DEAR_SOMETHING > >> DKIM_ADSP_CUSTOM_MED > >> FREEMAIL_FROM > >> LOTS_OF_MONEY > >> SPF_SOFTFAIL > >> T_MONEY_PERCENT > >> URG_BIZ > > > > comment out > > > > #tflags RCVD_IN_RP_TLDNS1 net > > > > run that msg against spamassassin -D dns > > see what it spits out > > sorry, no idea what you mean with "run that message against" > Under the same directory as spamass-milter run: spamc -your_normal_spamc_options
Re: writing own rbl rules
Am 26.08.2014 um 20:29 schrieb Axb: > On 08/26/2014 08:08 PM, Reindl Harald wrote: >> >> Am 26.08.2014 um 18:11 schrieb Axb: >>> On 08/26/2014 05:42 PM, Reindl Harald wrote: they are *not* i sepecially added the following lines to prevent the automatic adding to "trusted_networks" since the IP range is outside clear_trusted_networks trusted_networks 192.168.168.0/24 there was no trust at all in the headers and no hint why the DNSWL was skipped at all ADVANCE_FEE_4_NEW ADVANCE_FEE_4_NEW_MONEY ADVANCE_FEE_5_NEW ADVANCE_FEE_5_NEW_MONEY BAYES_99 BAYES_999 DEAR_SOMETHING DKIM_ADSP_CUSTOM_MED FREEMAIL_FROM LOTS_OF_MONEY SPF_SOFTFAIL T_MONEY_PERCENT URG_BIZ >>> >>> comment out >>> >>> #tflags RCVD_IN_RP_TLDNS1 net >>> >>> run that msg against spamassassin -D dns >>> see what it spits out >> >> sorry, no idea what you mean with "run that message against" >> >> spamassassin is running spamd and spamass-milter and no way >> to get the message passed over SMTP to that box with >> another configuration >> >> fact is that the message has no "ALL_TRUSTED" in the headers >> and it makes little sense that DNSWL lists are skipped only >> because the client is in the same network range because >> that makes behavior hard to test and compare >> >> that's (partly) how are the processes started >> /usr/bin/spamd -c -H --max-children=25 --min-children=10 --min-spare=5 >> --max-spare=15 --port=10027 >> /usr/sbin/spamass-milter -p /run/spamass-milter/spamass-milter.sock -g >> sa-milt -r 10 -- -s 1048576 --port=10027 > > fact is: you're making assumptions without making use of the basic > spamassassin command line debugging features i just don't know how to do that with the setup and mailflow by just start "spamassassin -D dns" which runs the process but how to get the mail there? yes, i make assumptions, but without touch anything else and having none of the IP's as "trusted" using the exact same message but from a IP outside the own subnet shows that rules are used signature.asc Description: OpenPGP digital signature
Re: writing own rbl rules
On 08/26/2014 08:08 PM, Reindl Harald wrote: Am 26.08.2014 um 18:11 schrieb Axb: On 08/26/2014 05:42 PM, Reindl Harald wrote: they are *not* i sepecially added the following lines to prevent the automatic adding to "trusted_networks" since the IP range is outside clear_trusted_networks trusted_networks 192.168.168.0/24 there was no trust at all in the headers and no hint why the DNSWL was skipped at all ADVANCE_FEE_4_NEW ADVANCE_FEE_4_NEW_MONEY ADVANCE_FEE_5_NEW ADVANCE_FEE_5_NEW_MONEY BAYES_99 BAYES_999 DEAR_SOMETHING DKIM_ADSP_CUSTOM_MED FREEMAIL_FROM LOTS_OF_MONEY SPF_SOFTFAIL T_MONEY_PERCENT URG_BIZ comment out #tflags RCVD_IN_RP_TLDNS1 net run that msg against spamassassin -D dns see what it spits out sorry, no idea what you mean with "run that message against" spamassassin is running spamd and spamass-milter and no way to get the message passed over SMTP to that box with another configuration fact is that the message has no "ALL_TRUSTED" in the headers and it makes little sense that DNSWL lists are skipped only because the client is in the same network range because that makes behavior hard to test and compare that's (partly) how are the processes started /usr/bin/spamd -c -H --max-children=25 --min-children=10 --min-spare=5 --max-spare=15 --port=10027 /usr/sbin/spamass-milter -p /run/spamass-milter/spamass-milter.sock -g sa-milt -r 10 -- -s 1048576 --port=10027 fact is: you're making assumptions without making use of the basic spamassassin command line debugging features. good luck!
Re: writing own rbl rules
Am 26.08.2014 um 18:11 schrieb Axb: > On 08/26/2014 05:42 PM, Reindl Harald wrote: >> they are *not* i sepecially added the following lines >> to prevent the automatic adding to "trusted_networks" >> since the IP range is outside >> >> clear_trusted_networks >> trusted_networks 192.168.168.0/24 >> >> there was no trust at all in the headers and no >> hint why the DNSWL was skipped at all >> >> ADVANCE_FEE_4_NEW >> ADVANCE_FEE_4_NEW_MONEY >> ADVANCE_FEE_5_NEW >> ADVANCE_FEE_5_NEW_MONEY >> BAYES_99 >> BAYES_999 >> DEAR_SOMETHING >> DKIM_ADSP_CUSTOM_MED >> FREEMAIL_FROM >> LOTS_OF_MONEY >> SPF_SOFTFAIL >> T_MONEY_PERCENT >> URG_BIZ > > comment out > > #tflags RCVD_IN_RP_TLDNS1 net > > run that msg against spamassassin -D dns > see what it spits out sorry, no idea what you mean with "run that message against" spamassassin is running spamd and spamass-milter and no way to get the message passed over SMTP to that box with another configuration fact is that the message has no "ALL_TRUSTED" in the headers and it makes little sense that DNSWL lists are skipped only because the client is in the same network range because that makes behavior hard to test and compare that's (partly) how are the processes started /usr/bin/spamd -c -H --max-children=25 --min-children=10 --min-spare=5 --max-spare=15 --port=10027 /usr/sbin/spamass-milter -p /run/spamass-milter/spamass-milter.sock -g sa-milt -r 10 -- -s 1048576 --port=10027 signature.asc Description: OpenPGP digital signature
Re: writing own rbl rules
On 08/26/2014 05:42 PM, Reindl Harald wrote: they are*not* i sepecially added the following lines to prevent the automatic adding to "trusted_networks" since the IP range is outside clear_trusted_networks trusted_networks 192.168.168.0/24 there was no trust at all in the headers and no hint why the DNSWL was skipped at all ADVANCE_FEE_4_NEW ADVANCE_FEE_4_NEW_MONEY ADVANCE_FEE_5_NEW ADVANCE_FEE_5_NEW_MONEY BAYES_99 BAYES_999 DEAR_SOMETHING DKIM_ADSP_CUSTOM_MED FREEMAIL_FROM LOTS_OF_MONEY SPF_SOFTFAIL T_MONEY_PERCENT URG_BIZ comment out #tflags RCVD_IN_RP_TLDNS1 net run that msg against spamassassin -D dns see what it spits out
Re: writing own rbl rules
Am 26.08.2014 um 17:30 schrieb Axb:
> On 08/26/2014 05:25 PM, Reindl Harald wrote:
>> Am 26.08.2014 um 17:18 schrieb Axb:
>>> On 08/26/2014 04:28 PM, Reindl Harald wrote:
header RCVD_IN_RP_TLDNS1 eval:check_rbl('tldns1-lastexternal',
'dnswl.thelounge.net.')
describe RCVD_IN_RP_TLDNS1 Custom DNSBL/DNSWL
tflags RCVD_IN_RP_TLDNS1 net
scoreRCVD_IN_RP_TLDNS1 -5
>>> assuming your using rbldnsd, do you have the resolver forwarding to the
>>> dnswl.thelounge.net zone?
>>> does dnswl.thelounge.net have an A record
>>> have you configured a testpoint in dnswl.thelounge.net? if yes, can you
>>> resolve it with dig?
>>
>> Agh - that rules are skipped in case of hosts from the
>> same network as the server - is there some way to disable
>> that behavior?
>>
>> in case of blacklists that may make sense
>> in case of DNSWL containing the own subnet a substract a large score not so
>>
>> i just added my public home-ip to the dnswl and made
>> a copy of the test-formmailer there pointing to the
>> mail-gateway running SA and now it works
>
> if you have your host IPs in internal/trusted networks
> what's the point of doing BL/WL lookups on those?
the most important point it that hidden magic makes
it hard to implement and test things - without that
i would have *hours ago* finished the backend and
cronjobs
we have for different weighted whitelists, i am about
write SA-rules for them to substract a different
score and the LAN is an all 4 of them
in fact the combined negative score would override much
more than the skip of RBL/DNSBL and the implicit trust
and even at testing with one DNSWL that would have
allowed a tagged testmessage which was blocked otherwise
until raise the threshold
> if that bothers you remove them from internal/trusted networks
they are *not* i sepecially added the following lines
to prevent the automatic adding to "trusted_networks"
since the IP range is outside
clear_trusted_networks
trusted_networks 192.168.168.0/24
there was no trust at all in the headers and no
hint why the DNSWL was skipped at all
ADVANCE_FEE_4_NEW
ADVANCE_FEE_4_NEW_MONEY
ADVANCE_FEE_5_NEW
ADVANCE_FEE_5_NEW_MONEY
BAYES_99
BAYES_999
DEAR_SOMETHING
DKIM_ADSP_CUSTOM_MED
FREEMAIL_FROM
LOTS_OF_MONEY
SPF_SOFTFAIL
T_MONEY_PERCENT
URG_BIZ
signature.asc
Description: OpenPGP digital signature
Re: writing own rbl rules
Am 26.08.2014 um 17:18 schrieb Axb:
> On 08/26/2014 04:28 PM, Reindl Harald wrote:
>> header RCVD_IN_RP_TLDNS1 eval:check_rbl('tldns1-lastexternal',
>> 'dnswl.thelounge.net.')
>> describe RCVD_IN_RP_TLDNS1 Custom DNSBL/DNSWL
>> tflags RCVD_IN_RP_TLDNS1 net
>> scoreRCVD_IN_RP_TLDNS1 -5
>>
>> spamd: result: Y 9 -
>> ADVANCE_FEE_4_NEW,ADVANCE_FEE_4_NEW_MONEY,ADVANCE_FEE_5_NEW,ADVANCE_FEE_5_NEW_MONEY,BAYES_99,BAYES_999,DEAR_SOMETHING,DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,LOTS_OF_MONEY,SPF_SOFTFAIL,T_MONEY_PERCENT,URG_BIZ
>>
>> scantime=0.4,size=8639,user=sa-milt,uid=189,required_score=1.0,rhost=localhost,raddr=127.0.0.1,rport=29655,mid=<762711c0cdde92c967fe5f98b4054c4ceadd18a41409062805@**>,bayes=1.00,autolearn=disabled
>
> assuming your using rbldnsd, do you have the resolver forwarding to the
> dnswl.thelounge.net zone?
> does dnswl.thelounge.net have an A record
> have you configured a testpoint in dnswl.thelounge.net? if yes, can you
> resolve it with dig?
Agh - that rules are skipped in case of hosts from the
same network as the server - is there some way to disable
that behavior?
in case of blacklists that may make sense
in case of DNSWL containing the own subnet a substract a large score not so
i just added my public home-ip to the dnswl and made
a copy of the test-formmailer there pointing to the
mail-gateway running SA and now it works
Aug 26 17:20:42 mail-gw spamd[23363]: spamd: result: Y 4 -
ADVANCE_FEE_4_NEW,ADVANCE_FEE_4_NEW_MONEY,ADVANCE_FEE_5_NEW,ADVANCE_FEE_5_NEW_MONEY,BAYES_99,BAYES_999,DEAR_SOMETHING,DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,LOTS_OF_MONEY,RCVD_IN_RP_TLDNS1,SPF_SOFTFAIL,T_MONEY_PERCENT,URG_BIZ
scantime=0.2,size=4753,user=sa-milt,uid=189,required_score=1.0,rhost=localhost,raddr=127.0.0.1,rport=29708,mid=<22e76ecfb06bf34da4f059a5606a8ffe7a93c3471409066...@srv-rhsoft.rhsoft.net>,bayes=1.00,autolearn=disabled
signature.asc
Description: OpenPGP digital signature
Re: writing own rbl rules
On 08/26/2014 05:25 PM, Reindl Harald wrote:
Am 26.08.2014 um 17:18 schrieb Axb:
On 08/26/2014 04:28 PM, Reindl Harald wrote:
header RCVD_IN_RP_TLDNS1 eval:check_rbl('tldns1-lastexternal',
'dnswl.thelounge.net.')
describe RCVD_IN_RP_TLDNS1 Custom DNSBL/DNSWL
tflags RCVD_IN_RP_TLDNS1 net
scoreRCVD_IN_RP_TLDNS1 -5
spamd: result: Y 9 -
ADVANCE_FEE_4_NEW,ADVANCE_FEE_4_NEW_MONEY,ADVANCE_FEE_5_NEW,ADVANCE_FEE_5_NEW_MONEY,BAYES_99,BAYES_999,DEAR_SOMETHING,DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,LOTS_OF_MONEY,SPF_SOFTFAIL,T_MONEY_PERCENT,URG_BIZ
scantime=0.4,size=8639,user=sa-milt,uid=189,required_score=1.0,rhost=localhost,raddr=127.0.0.1,rport=29655,mid=<762711c0cdde92c967fe5f98b4054c4ceadd18a41409062805@**>,bayes=1.00,autolearn=disabled
assuming your using rbldnsd, do you have the resolver forwarding to the
dnswl.thelounge.net zone?
does dnswl.thelounge.net have an A record
have you configured a testpoint in dnswl.thelounge.net? if yes, can you resolve
it with dig?
Agh - that rules are skipped in case of hosts from the
same network as the server - is there some way to disable
that behavior?
in case of blacklists that may make sense
in case of DNSWL containing the own subnet a substract a large score not so
i just added my public home-ip to the dnswl and made
a copy of the test-formmailer there pointing to the
mail-gateway running SA and now it works
if you have your host IPs in internal/trusted networks what's the point
of doing BL/WL lookups on those?
if that bothers you remove them from internal/trusted networks
Re: writing own rbl rules
On 08/26/2014 04:28 PM, Reindl Harald wrote:
Am 26.08.2014 um 15:54 schrieb Axb:
On 08/26/2014 03:00 PM, Reindl Harald wrote:
Am 26.08.2014 um 14:25 schrieb Joe Quinn:
On 8/26/2014 8:04 AM, Reindl Harald wrote:
sadly the Wiki don't refer to check_rbl()
https://wiki.apache.org/spamassassin/WritingRules
You can use KAM.cf for reference.
http://www.pccc.com/downloads/SpamAssassin/contrib/KAM.cf
Search for KAM_FROM_URIBL_PCCC
thanks, looks like the missing identifier as first
params was the reason for the error but the rule
below still don't fire and the connecting IP is
on the list, recently verified again
may the problem be that "header" looks in received
headers and not at the connecting physical IP?
header RCVD_IN_TL_DNSWL_HIGH eval:check_rbl('custom-dns-1',
'dnswl.thelounge.net.', '127.0.0.2')
describe RCVD_IN_TL_DNSWL_HIGH Custom DNSBL/DNSWL
tflags RCVD_IN_TL_DNSWL_HIGH net
scoreRCVD_IN_TL_DNSWL_HIGH -5
see 20_dnsbl_tests.cf file for a "lastexternal" sample
if it only would work - see below
the 4 lines are part of "local.cf" where other settings
are working fine - strange :-(
* example
* mine
* log-result
# Return Path Reputation Network Blacklist (RNBL):
# https://senderscore.org/blacklistlookup/
header RCVD_IN_RP_RNBL
eval:check_rbl('rnbl-lastexternal','bl.score.senderscore.com.')
describe RCVD_IN_RP_RNBL Relay in RNBL,
https://senderscore.org/blacklistlookup/
tflags RCVD_IN_RP_RNBL net
header RCVD_IN_RP_TLDNS1 eval:check_rbl('tldns1-lastexternal',
'dnswl.thelounge.net.')
describe RCVD_IN_RP_TLDNS1 Custom DNSBL/DNSWL
tflags RCVD_IN_RP_TLDNS1 net
scoreRCVD_IN_RP_TLDNS1 -5
spamd: result: Y 9 -
ADVANCE_FEE_4_NEW,ADVANCE_FEE_4_NEW_MONEY,ADVANCE_FEE_5_NEW,ADVANCE_FEE_5_NEW_MONEY,BAYES_99,BAYES_999,DEAR_SOMETHING,DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,LOTS_OF_MONEY,SPF_SOFTFAIL,T_MONEY_PERCENT,URG_BIZ
scantime=0.4,size=8639,user=sa-milt,uid=189,required_score=1.0,rhost=localhost,raddr=127.0.0.1,rport=29655,mid=<762711c0cdde92c967fe5f98b4054c4ceadd18a41409062805@**>,bayes=1.00,autolearn=disabled
assuming your using rbldnsd, do you have the resolver forwarding to the
dnswl.thelounge.net zone?
does dnswl.thelounge.net have an A record
have you configured a testpoint in dnswl.thelounge.net? if yes, can you
resolve it with dig?
Re: writing own rbl rules
Am 26.08.2014 um 15:54 schrieb Axb:
> On 08/26/2014 03:00 PM, Reindl Harald wrote:
>> Am 26.08.2014 um 14:25 schrieb Joe Quinn:
>>> On 8/26/2014 8:04 AM, Reindl Harald wrote:
sadly the Wiki don't refer to check_rbl()
https://wiki.apache.org/spamassassin/WritingRules
>>> You can use KAM.cf for reference.
>>>
>>> http://www.pccc.com/downloads/SpamAssassin/contrib/KAM.cf
>>> Search for KAM_FROM_URIBL_PCCC
>>
>> thanks, looks like the missing identifier as first
>> params was the reason for the error but the rule
>> below still don't fire and the connecting IP is
>> on the list, recently verified again
>>
>> may the problem be that "header" looks in received
>> headers and not at the connecting physical IP?
>>
>> header RCVD_IN_TL_DNSWL_HIGH eval:check_rbl('custom-dns-1',
>> 'dnswl.thelounge.net.', '127.0.0.2')
>> describe RCVD_IN_TL_DNSWL_HIGH Custom DNSBL/DNSWL
>> tflags RCVD_IN_TL_DNSWL_HIGH net
>> scoreRCVD_IN_TL_DNSWL_HIGH -5
>
> see 20_dnsbl_tests.cf file for a "lastexternal" sample
if it only would work - see below
the 4 lines are part of "local.cf" where other settings
are working fine - strange :-(
* example
* mine
* log-result
# Return Path Reputation Network Blacklist (RNBL):
# https://senderscore.org/blacklistlookup/
header RCVD_IN_RP_RNBL
eval:check_rbl('rnbl-lastexternal','bl.score.senderscore.com.')
describe RCVD_IN_RP_RNBL Relay in RNBL,
https://senderscore.org/blacklistlookup/
tflags RCVD_IN_RP_RNBL net
header RCVD_IN_RP_TLDNS1 eval:check_rbl('tldns1-lastexternal',
'dnswl.thelounge.net.')
describe RCVD_IN_RP_TLDNS1 Custom DNSBL/DNSWL
tflags RCVD_IN_RP_TLDNS1 net
scoreRCVD_IN_RP_TLDNS1 -5
spamd: result: Y 9 -
ADVANCE_FEE_4_NEW,ADVANCE_FEE_4_NEW_MONEY,ADVANCE_FEE_5_NEW,ADVANCE_FEE_5_NEW_MONEY,BAYES_99,BAYES_999,DEAR_SOMETHING,DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,LOTS_OF_MONEY,SPF_SOFTFAIL,T_MONEY_PERCENT,URG_BIZ
scantime=0.4,size=8639,user=sa-milt,uid=189,required_score=1.0,rhost=localhost,raddr=127.0.0.1,rport=29655,mid=<762711c0cdde92c967fe5f98b4054c4ceadd18a41409062805@**>,bayes=1.00,autolearn=disabled
signature.asc
Description: OpenPGP digital signature
Re: writing own rbl rules
On 08/26/2014 03:00 PM, Reindl Harald wrote:
Am 26.08.2014 um 14:25 schrieb Joe Quinn:
On 8/26/2014 8:04 AM, Reindl Harald wrote:
i am tyring to write own RBL rules for blacklisting and
especially whitelisting using internal DNSBL/DNSWL but
my first try results in warnings at startup
sadly the Wiki don't refer to check_rbl()
https://wiki.apache.org/spamassassin/WritingRules
ifplugin Mail::SpamAssassin::Plugin::DNSEval
header RCVD_IN_TL_DNSWL_HIGH eval:check_rbl('dnswl.thelounge.net')
tflags RCVD_IN_TL_DNSWL_HIGH net
endif
Aug 26 13:56:07 mail-gw spamd[19589]: Use of uninitialized value $rbl_server in
pattern match (m//) at
/usr/share/perl5/vendor_perl/Mail/SpamAssassin/Plugin/DNSEval.pm line 156.
Aug 26 13:56:07 mail-gw spamd[19589]: Use of uninitialized value $rbl_server in
index at
/usr/share/perl5/vendor_perl/Mail/SpamAssassin/Plugin/DNSEval.pm line 156.
Aug 26 13:56:07 mail-gw spamd[19589]: Use of uninitialized value $rbl_server in
concatenation (.) or string at
/usr/share/perl5/vendor_perl/Mail/SpamAssassin/Plugin/DNSEval.pm line 162.
You can use KAM.cf for reference.
http://www.pccc.com/downloads/SpamAssassin/contrib/KAM.cf
Search for KAM_FROM_URIBL_PCCC
thanks, looks like the missing identifier as first
params was the reason for the error but the rule
below still don't fire and the connecting IP is
on the list, recently verified again
may the problem be that "header" looks in received
headers and not at the connecting physical IP?
header RCVD_IN_TL_DNSWL_HIGH eval:check_rbl('custom-dns-1',
'dnswl.thelounge.net.', '127.0.0.2')
describe RCVD_IN_TL_DNSWL_HIGH Custom DNSBL/DNSWL
tflags RCVD_IN_TL_DNSWL_HIGH net
scoreRCVD_IN_TL_DNSWL_HIGH -5
see 20_dnsbl_tests.cf file for a "lastexternal" sample
Re: writing own rbl rules
Am 26.08.2014 um 14:25 schrieb Joe Quinn:
> On 8/26/2014 8:04 AM, Reindl Harald wrote:
>> i am tyring to write own RBL rules for blacklisting and
>> especially whitelisting using internal DNSBL/DNSWL but
>> my first try results in warnings at startup
>>
>> sadly the Wiki don't refer to check_rbl()
>> https://wiki.apache.org/spamassassin/WritingRules
>>
>> ifplugin Mail::SpamAssassin::Plugin::DNSEval
>> header RCVD_IN_TL_DNSWL_HIGH eval:check_rbl('dnswl.thelounge.net')
>> tflags RCVD_IN_TL_DNSWL_HIGH net
>> endif
>>
>> Aug 26 13:56:07 mail-gw spamd[19589]: Use of uninitialized value $rbl_server
>> in pattern match (m//) at
>> /usr/share/perl5/vendor_perl/Mail/SpamAssassin/Plugin/DNSEval.pm line 156.
>> Aug 26 13:56:07 mail-gw spamd[19589]: Use of uninitialized value $rbl_server
>> in index at
>> /usr/share/perl5/vendor_perl/Mail/SpamAssassin/Plugin/DNSEval.pm line 156.
>> Aug 26 13:56:07 mail-gw spamd[19589]: Use of uninitialized value $rbl_server
>> in concatenation (.) or string at
>> /usr/share/perl5/vendor_perl/Mail/SpamAssassin/Plugin/DNSEval.pm line 162.
>>
> You can use KAM.cf for reference.
>
> http://www.pccc.com/downloads/SpamAssassin/contrib/KAM.cf
> Search for KAM_FROM_URIBL_PCCC
thanks, looks like the missing identifier as first
params was the reason for the error but the rule
below still don't fire and the connecting IP is
on the list, recently verified again
may the problem be that "header" looks in received
headers and not at the connecting physical IP?
header RCVD_IN_TL_DNSWL_HIGH eval:check_rbl('custom-dns-1',
'dnswl.thelounge.net.', '127.0.0.2')
describe RCVD_IN_TL_DNSWL_HIGH Custom DNSBL/DNSWL
tflags RCVD_IN_TL_DNSWL_HIGH net
scoreRCVD_IN_TL_DNSWL_HIGH -5
signature.asc
Description: OpenPGP digital signature
Re: writing own rbl rules
On 8/26/2014 8:04 AM, Reindl Harald wrote:
Hi
i am tyring to write own RBL rules for blacklisting and
especially whitelisting using internal DNSBL/DNSWL but
my first try results in warnings at startup
sadly the Wiki don't refer to check_rbl()
https://wiki.apache.org/spamassassin/WritingRules
ifplugin Mail::SpamAssassin::Plugin::DNSEval
header RCVD_IN_TL_DNSWL_HIGH eval:check_rbl('dnswl.thelounge.net')
tflags RCVD_IN_TL_DNSWL_HIGH net
endif
Aug 26 13:56:07 mail-gw spamd[19589]: Use of uninitialized value $rbl_server in
pattern match (m//) at
/usr/share/perl5/vendor_perl/Mail/SpamAssassin/Plugin/DNSEval.pm line 156.
Aug 26 13:56:07 mail-gw spamd[19589]: Use of uninitialized value $rbl_server in
index at
/usr/share/perl5/vendor_perl/Mail/SpamAssassin/Plugin/DNSEval.pm line 156.
Aug 26 13:56:07 mail-gw spamd[19589]: Use of uninitialized value $rbl_server in
concatenation (.) or string at
/usr/share/perl5/vendor_perl/Mail/SpamAssassin/Plugin/DNSEval.pm line 162.
You can use KAM.cf for reference.
http://www.pccc.com/downloads/SpamAssassin/contrib/KAM.cf
Search for KAM_FROM_URIBL_PCCC
