Recently I was in discussion with the creator of a URI_SHORTENER black list
maintainer that created a list of domains handling short URLs. (You can
find his full rule and details here:
http://snork.ca/posts/2016-06-24-surbl-of-url-shorteners-for-spamassassin/).
He has identified over 200 CURRENT
Thanks for the replies guys
So in essence, there is no user friendly method as there were before.
On 09/06/2016 14:19, Joe Quinn wrote:
> I have a bookmark in Firefox that points to
> http://ruleqa.spamassassin.org/?rule=%s&srcpath=&g=Change which is the
> status page for the nightly rule updates
On 09/06/2016 16:57, Sidney Markowitz [via SpamAssassin] wrote:
> As to why you should have to list all the internal ip addresses again
> in the
> list of trusted ones ... Because the people who designed this had to
> keep all
> this in their head at one time and they did by thinking "This is the
(Note: For clarity, the
https://spamassassin.apache.org/full/3.4.x/doc/Mail_SpamAssassin_Conf.html
link you provided IS the page I refer to when I say "reading the wiki".)
Ok, reading it again: it says
/
//"trusted_networks IPaddress[/masklen] ... (default: none)//
//
//What networks or hos
Once upon a time the include rules for spamassassin was published in its wiki
(example here: http://spamassassin.apache.org/tests_3_3_x.html) which in
turn gave a link to an 'explanation' detail of the individual rules.
However, as you know, these wiki ages are no longer updated due to "rules
bein
FEEDBACK for all who have contributed:
I have a result.
It seems that the 'internal_networks' is only adhered to *in the absence* of
a 'trusted_networks' entry. If I remove the 'trusted_networks', and simply
leave:
internal_networks 195.26.90.
then it is correctly applied:
X-Spam-Report:
Yes it is but it all still works just as the linux version does. So is
irrelevant actually (the only difference being its easier to install and
setup on windows.
--
View this message in context:
http://spamassassin.1065346.n5.nabble.com/Advice-why-one-relay-evaluated-and-not-the-other-tp1211
If you think the foxhole databases are not sufficient enough and that other
extensions are required, then contact Steve @ Sane to discuss/request:
http://sanesecurity.com/contact-us/. I speak to him regularly and is open
to feedback.
Chip M. wrote
> At 04:07 AM 5/20/2016, Dianne/RoaringPenguin wr
On 08/06/2016 21:26, David B Funk [via SpamAssassin] wrote:
> This sounds like a config file confusion issue. IE the SA that you are
> running
> is looking at different config files than the ones that you are editing
> or some config file that is being read -after- your expected config files
> is
On 08/06/2016 16:05, Matus UHLAR - fantomas [via SpamAssassin] wrote:
> note that if a server acts as your MX, it should be listed in
> internal_networks, no matter if other company manages it.
>
> That applies for backup MX servers for your domain, or, even primary
> MX if
> you fetch mail from
ne?
TIA
On 08/06/2016 14:59, Kevin Golding-2 [via SpamAssassin] wrote:
> On Wed, 08 Jun 2016 13:49:17 +0100, jimimaseye
> <[hidden email] > wrote:
>
> > Regarding the range: the range belongs to our mail host provider who
> > receive the emails then pass them amongst
On 08/06/2016 14:51, RW-15 [via SpamAssassin] wrote:
> > * internal_networks 195.26.90.*
>
> Try to avoid using any mark-up (assuming that's what the "*"s are), it
> can be very confusing.
>
Noted. And well observed. (The asterix was markup (bold) not wildcard
entered by me.)
> > X-Mailer: Ap
:14 +0100, jimimaseye
>
> That syntax is wrong, it's the same as trusted_networks so you don't use
> the wildcard. You can use CIDR too if you want, but not *
>
> In fact they may be better as trusted_networks anyway - it all depends
> what role they play in your setup
&g
Kevin Golding-2 wrote
> Given the PBL listing is only the last external IP the fact that SA is
> testing headers in your internal network explains why it's not testing an
> IP one hop further out. Essentially it seems as if your internal_networks
> is incorrectly set. Or, as your pasted confi
Hi
I run an MTA (Hmailserver) that passes its mail through Spamassassin 3.4.1
on receiving emails. Currently the mail is 'collected' via POP from an
external mail host, then put through SA, then subjects the email to its own
internal anti-spam checks (such as SURBL and DNSBL lookups), and then de
15 matches
Mail list logo
