Re: RBL via Spamassasin configuration
META: The message below seems to be a reply to a message by Harald Reindl, who was blocked from posting to this mailing list in the past for chronic unreasonably combative behavior. Unfortunately, there's no way to stop him from reading this mailing list via any of the public archives or a 'stealth' subscription, and he still injects his special flavor of discourse into the conversation by sending mail directly to list members instead of via the list. On 2022-06-28 at 17:22:51 UTC-0400 (Tue, 28 Jun 2022 21:22:51 +) Marc is rumored to have said: BTW: "spammers also strife to optimize the usage of their resources" shows that you know little to nothing! they are using infected machines all over they world that bot's are running completly without any feedback because it would make it possible to track the origin even if: other than the bots for free *it would* take rsources to collect the reject states from millions of boths spear all over the planet If your spam network is 10% effective instead of 1% you can ask a higher price for your service. So you want to make sure you addresses are up to date. Even if you have a bot network that does not report back you still use a small % that does inform you. The universal goal is to optimize, this is not different for spammers. That you can not think of a way to optimize spamming, does not mean they are not doing it. It is very difficult to analyse and argue this, unless you really target your logging for this. Because if your clients fluctuate, also your email traffic fluctuates, your email traffic even fluctuates on periods of the year. I see a drop in the garbage (connections) coming from your-server.de since I put them on the connection blocking. It does not mean anything unless I start grabbing the message bodies before sending the reject. If you conclude something based on some month, there is no going back on this. I know people in IT that did not learn anything in 15 years. As for now, I am not really convinced by your arguments. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
Re: RBL via Spamassasin configuration
On 2022-06-29 10:25, Matus UHLAR - fantomas wrote: Since SpamAssassin does deep header scanning, it's more effective than just use incoming IP at MTA level. On 29.06.22 10:58, Benny Pedersen wrote: this is not good, its a sign of forwarding that forwards spam in the first place, that make the forwarding ip grey, not white/wellcommed, same shit as sendgrid does SA does this for years and it works perfectly. SA can detect from which IP was mail delivered to your network (not just to direct server that uses SA) and check that IP in DNSBLs, instead of only checking IP of nearest mailserver. not all headers are checked in all DNSBLs, but SA can check much more than MTA. -- 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. Windows found: (R)emove, (E)rase, (D)elete
Re: RBL via Spamassasin configuration
On 2022-06-29 11:05, Marc wrote: I don't really get what you wrote. There is something for blocking at ip level, least resource intensive, and there is an application for doing the advanced header/body scans at a later stage. dont use deap ip scanning on dnsbl use deap content scanning is ok, that includes urlbl stop cc me, i am still read maillists
RE: RBL via Spamassasin configuration
> > On 2022-06-29 10:25, Matus UHLAR - fantomas wrote: > > Since SpamAssassin does deep header scanning, it's more effective than > > just use incoming IP at MTA level. > > this is not good, its a sign of forwarding that forwards spam in the > first place, that make the forwarding ip grey, not white/wellcommed, > same shit as sendgrid does > > if sendgrid changes to use pr domain sender ips then sendgrid have > solved it 100%, but that say we have bilions custommers so that cant, > lol I don't really get what you wrote. There is something for blocking at ip level, least resource intensive, and there is an application for doing the advanced header/body scans at a later stage.
Re: RBL via Spamassasin configuration
On 2022-06-29 10:25, Matus UHLAR - fantomas wrote: Since SpamAssassin does deep header scanning, it's more effective than just use incoming IP at MTA level. this is not good, its a sign of forwarding that forwards spam in the first place, that make the forwarding ip grey, not white/wellcommed, same shit as sendgrid does if sendgrid changes to use pr domain sender ips then sendgrid have solved it 100%, but that say we have bilions custommers so that cant, lol
Re: RBL via Spamassasin configuration
Is this actually going out and doing a DNS query or reading from the header of the message? I think I want to actually do the DNS query and I will cache locally to avoid issues and increase performance. That is what dns servers do, cache. If you have your local dns, these requests are probably faster than spamassassin rule processing. just don't use forwarding nameserver, it would The last part of my question is, here we score and then based on scoring the next part can either quarantine the message or deliver it, but is there a way from SA to simply say reject it right there? you can reject with SA ad MTA level, just use one of milters available. spamass-milter, amavisd-milter or others. Just don't reject with standard spam score, with well-trained BAYES I reject score over 8 (10 without proper BAYES training) On 28.06.22 18:56, Marc wrote: Why not use the dns blacklist at the mta? And reject the messages even before they are using spamassassin. Imho you should apply simple/basic/fast checks first and at the end use resource intensive tasks like spamassassin. you can use multiple DNS Blocklists at MTA level (it's often not safe enough to accept match from single DNSBL) and use them within SA too. Since SpamAssassin does deep header scanning, it's more effective than just use incoming IP at MTA level. -- 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: RBL via Spamassasin configuration
On 2022-06-29 02:56, Joey J wrote:
Hello All, not sure where I'm going wrong.
in my custom.cf [3] I have
#RBL's
header RCVD_IN_ZENSPAMHAUS eval:check_rbl('zenspamhaus-lastexternal',
'zen.spamhaus.org.')
describe RCVD_IN_ZENSPAMHAUS Relay is listed in zen.spamhaus.org [4]
tflags RCVD_IN_ZENSPAMHAUS net
score RCVD_IN_ZENSPAMHAUS 5.0
zen.spamhaus.org is already in spamassassin, why redefine it ?
Re: RBL via Spamassasin configuration
On 2022-06-28 23:22, Marc wrote: If you conclude something based on some month, there is no going back on this. I know people in IT that did not learn anything in 15 years. As for now, I am not really convinced by your arguments. Subject RE: RBL via Spamassasin configuration FromMarc To Reindl Harald, Joey J, users@spamassassin.apache.org Date2022-06-28 23:22 why do you send to others ?, is this not being spammer on its own ? doh :)
Re: RBL via Spamassasin configuration
Hello All, not sure where I'm going wrong.
in my custom.cf I have
#RBL's
header RCVD_IN_ZENSPAMHAUS eval:check_rbl('zenspamhaus-lastexternal',
'zen.spamhaus.org.')
describe RCVD_IN_ZENSPAMHAUS Relay is listed in zen.spamhaus.org
tflags RCVD_IN_ZENSPAMHAUS net
score RCVD_IN_ZENSPAMHAUS 5.0
if I query DNS, I get the expected answer from local caching:
dig +short TXT 2.0.0.127.zen.spamhaus.org
"https://www.spamhaus.org/sbl/query/SBL2";
"https://www.spamhaus.org/query/ip/127.0.0.2";
When I send a test message using Access the Portal – Blocklist Tester |
Spamhaus
Re: RBL via Spamassasin configuration
Thank you, this makes sense, I will look through the mentioned resource.
On Tue, Jun 28, 2022 at 5:28 PM Bill Cole <
sausers-20150...@billmail.scconsult.com> wrote:
> On 2022-06-28 at 14:38:16 UTC-0400 (Tue, 28 Jun 2022 14:38:16 -0400)
> Joey J
> is rumored to have said:
>
> > Hello All,
> >
> > In trying to setup RBL's with SA, I wanted to make sure the proper way
> > to
> > do it.
> > I have seen some samples like this
> > header RCVD_IN_BARRACUDACEN eval:check_rbl('bbarracuda-lastexternal',
> > 'b.barracudacentral.org.')
> > describe RCVD_IN_BARRACUDACEN Relay is listed in
> > b.barracudacentral.org
> > tflags RCVD_IN_BARRACUDACEN net
> > score RCVD_IN_BARRACUDACEN 4.0
>
> That looks right. Definitive documentation can be had with 'perldoc
> Mail::SpamAssassin::Plugin::DNSEval' and 'perldoc
> Mail::SpamAssassin::Conf'
>
> > Is this actually going out and doing a DNS query or reading from the
> > header
> > of the message?
>
> It does both...
>
> SA analyzes the Received headers in a message to find relevant SMTP
> handoffs, with relevant settings in trusted_networks, internal_networks,
> and msa_networks. For DNSBLs, typically the "last external" Recceived
> heasder is the key: the latest one written by a trusted machine,
> documenting a handoff from a machine which is not in any of those
> special sets. It tests the IP address of that last external machine to
> handle the message. DNSEval looks up that IP address in the DNSBL.
>
> > I think I want to actually do the DNS query and I will cache locally
> > to
> > avoid issues and increase performance.
>
> The proper way to do this is to run a local caching recursive resolver
> (e.g. Unbound or BIND, NOT dnsmasq) on the same machine as the MTA and
> use that for all DNS lookups. Using more distant DNS servers can result
> in latency delays and using forwarding of any sort will cause blocking
> by DNSBL services. Any DNS server that filters or modifies responses to
> 'protect' user personal computers is unfit for use with email.
>
> > Also if someone has a list of these rules, that they use and could
> > share
> > that would be great.
>
> There are many in the standard ruleset. I think we do a reasonably good
> job of curating them, and they should all be safe to use as designed.
> Note that some DNSBLs are explicitly NOT intended for use on a mail
> server that accepts initial submission from end users.
>
> > The last part of my question is, here we score and then based on
> > scoring
> > the next part can either quarantine the message or deliver it, but is
> > there
> > a way from SA to simply say reject it right there?
> > (I think the answer is no, it simply scores it, but wanted to be sure)
>
> SpamAssassin itself has no capacity to handle the disposition of email.
> It only scores messages and reports those scores to whatever tool is
> using it.
>
> Hence, if you are accepting or quarantining mail based on a SA score,
> there's Something Else making that disposition decision. It might be a
> milter (MIMEDefang, MailMunge, spamass-milter, or amavisd-milter,) or a
> Postfix content_filter script or a SMTP proxy (many amavisd systems) or
> an Exim config stanza (not sure if that's an 'acl' or a 'router' in Exim
> jargon.) It is that 'glue' between the MTA and SA which implements the
> handling decision for scored messages.
>
> Generally it is a good idea to reject messages that you are not going to
> deliver. As a backstop for false positives rejection alerts the sender
> to the problem, in contrast to the silent death of quarantining.
> Quarantining (or worse, discarding) borderline messages may seem good in
> that it doesn't give any feedback to spammers, but in practice there's
> no evidence that they use the sort of feedback they get from rejections
> in any way. The simplest way they might do so in theory, washing bad
> addresses out of their lists, would actually be GOOD if they all did it.
>
>
>
>
> --
> Bill Cole
> b...@scconsult.com or billc...@apache.org
> (AKA @grumpybozo and many *@billmail.scconsult.com addresses)
> Not Currently Available For Hire
>
--
Thanks!
Joey
RE: RBL via Spamassasin configuration
> biggest nonsense at all when it comes to spammes given that i added some > hundrets addresses never existed to collect the bodies for trainign and > for the outisde world they are still rejects (milter) How is the guessing of existing email addresses relevant to the current discussion?
Re: RBL via Spamassasin configuration
On 2022-06-28 at 14:38:16 UTC-0400 (Tue, 28 Jun 2022 14:38:16 -0400)
Joey J
is rumored to have said:
Hello All,
In trying to setup RBL's with SA, I wanted to make sure the proper way
to
do it.
I have seen some samples like this
header RCVD_IN_BARRACUDACEN eval:check_rbl('bbarracuda-lastexternal',
'b.barracudacentral.org.')
describe RCVD_IN_BARRACUDACEN Relay is listed in
b.barracudacentral.org
tflags RCVD_IN_BARRACUDACEN net
score RCVD_IN_BARRACUDACEN 4.0
That looks right. Definitive documentation can be had with 'perldoc
Mail::SpamAssassin::Plugin::DNSEval' and 'perldoc
Mail::SpamAssassin::Conf'
Is this actually going out and doing a DNS query or reading from the
header
of the message?
It does both...
SA analyzes the Received headers in a message to find relevant SMTP
handoffs, with relevant settings in trusted_networks, internal_networks,
and msa_networks. For DNSBLs, typically the "last external" Recceived
heasder is the key: the latest one written by a trusted machine,
documenting a handoff from a machine which is not in any of those
special sets. It tests the IP address of that last external machine to
handle the message. DNSEval looks up that IP address in the DNSBL.
I think I want to actually do the DNS query and I will cache locally
to
avoid issues and increase performance.
The proper way to do this is to run a local caching recursive resolver
(e.g. Unbound or BIND, NOT dnsmasq) on the same machine as the MTA and
use that for all DNS lookups. Using more distant DNS servers can result
in latency delays and using forwarding of any sort will cause blocking
by DNSBL services. Any DNS server that filters or modifies responses to
'protect' user personal computers is unfit for use with email.
Also if someone has a list of these rules, that they use and could
share
that would be great.
There are many in the standard ruleset. I think we do a reasonably good
job of curating them, and they should all be safe to use as designed.
Note that some DNSBLs are explicitly NOT intended for use on a mail
server that accepts initial submission from end users.
The last part of my question is, here we score and then based on
scoring
the next part can either quarantine the message or deliver it, but is
there
a way from SA to simply say reject it right there?
(I think the answer is no, it simply scores it, but wanted to be sure)
SpamAssassin itself has no capacity to handle the disposition of email.
It only scores messages and reports those scores to whatever tool is
using it.
Hence, if you are accepting or quarantining mail based on a SA score,
there's Something Else making that disposition decision. It might be a
milter (MIMEDefang, MailMunge, spamass-milter, or amavisd-milter,) or a
Postfix content_filter script or a SMTP proxy (many amavisd systems) or
an Exim config stanza (not sure if that's an 'acl' or a 'router' in Exim
jargon.) It is that 'glue' between the MTA and SA which implements the
handling decision for scored messages.
Generally it is a good idea to reject messages that you are not going to
deliver. As a backstop for false positives rejection alerts the sender
to the problem, in contrast to the silent death of quarantining.
Quarantining (or worse, discarding) borderline messages may seem good in
that it doesn't give any feedback to spammers, but in practice there's
no evidence that they use the sort of feedback they get from rejections
in any way. The simplest way they might do so in theory, washing bad
addresses out of their lists, would actually be GOOD if they all did it.
--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
RE: RBL via Spamassasin configuration
> BTW: "spammers also strife to optimize the usage of their resources" > shows that you know little to nothing! > > they are using infected machines all over they world > > that bot's are running completly without any feedback because it would > make it possible to track the origin > > even if: other than the bots for free *it would* take rsources to > collect the reject states from millions of boths spear all over the > planet If your spam network is 10% effective instead of 1% you can ask a higher price for your service. So you want to make sure you addresses are up to date. Even if you have a bot network that does not report back you still use a small % that does inform you. The universal goal is to optimize, this is not different for spammers. That you can not think of a way to optimize spamming, does not mean they are not doing it. It is very difficult to analyse and argue this, unless you really target your logging for this. Because if your clients fluctuate, also your email traffic fluctuates, your email traffic even fluctuates on periods of the year. I see a drop in the garbage (connections) coming from your-server.de since I put them on the connection blocking. It does not mean anything unless I start grabbing the message bodies before sending the reject. If you conclude something based on some month, there is no going back on this. I know people in IT that did not learn anything in 15 years. As for now, I am not really convinced by your arguments.
RE: RBL via Spamassasin configuration
> > > Am 28.06.22 um 20:56 schrieb Marc: > > I also believe there is an advantage in rejecting messages, compared > to just marking them. Rejecting messages will train spam systems not to > try more. > > If they know you allow messages through, they will only send you more > > that's nonsense - otherwise "they" would stop sending me messages with > at the MTA hard rejected subjects It is not nonsense. It is common logic. Business processes are being optimized, spammers also strife to optimize the usage of their resources. Bouncing messages are messages not delivered and get noticed, resulting in bot's being discovered and cleaned. PS. It is also a bit 'dumb' to conclude this from a months sample, before the information trickles through to the address lists, it takes months I would assume.
RE: RBL via Spamassasin configuration
> In trying to setup RBL's with SA, I wanted to make sure the proper way
> to do it.
> I have seen some samples like this
> header RCVD_IN_BARRACUDACEN eval:check_rbl('bbarracuda-lastexternal',
> 'b.barracudacentral.org.')
> describe RCVD_IN_BARRACUDACEN Relay is listed in b.barracudacentral.org
>
> tflags RCVD_IN_BARRACUDACEN net
> score RCVD_IN_BARRACUDACEN 4.0
Maybe add/choose the value?
header RCVD_IN_EXAMPLE_RBL eval:check_rbl('example', 'rbl.example.com.',
'127.0.0.1')
I have always had issues with barracuda's false positives, are you sure you
want to use them?
>
> Is this actually going out and doing a DNS query or reading from the
> header of the message?
> I think I want to actually do the DNS query and I will cache locally to
> avoid issues and increase performance.
That is what dns servers do, cache. If you have your local dns, these requests
are probably faster than spamassassin rule processing.
>
>
> The last part of my question is, here we score and then based on scoring
> the next part can either quarantine the message or deliver it, but is
> there a way from SA to simply say reject it right there?
Why not use the dns blacklist at the mta? And reject the messages even before
they are using spamassassin. Imho you should apply simple/basic/fast checks
first and at the end use resource intensive tasks like spamassassin.
I also believe there is an advantage in rejecting messages, compared to just
marking them. Rejecting messages will train spam systems not to try more.
If they know you allow messages through, they will only send you more.
