Spamassassin default SHORT_URI list obsolete/outdated

[jimimaseye]

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 url shorteners and maintains them
accordingly (viewable here:
http://snork.ca/posts/2016-06-24-surbl-of-url-shorteners-for-spamassassin/url_shorteners.txt).

I then informed him that SA alreadyhas a URL_SHORTENER checking rule found
in 72_ACTIVE.CF.  I was currently using this as a META rule thus:

meta MY_URI_URLSHORT __URL_SHORTENER  # defined in 72_active.cf

He quite rightly pointed out that the 43 included shortener domains that SA
checks for in the default rule is drastically short and outdated (some even
dont exist anymore) compared to his more current recently 200 researched
list.

Is there any way that maybe the default list that SA checks for in 72_ACTIVE
can be updated and how is this request made or implemented?  (Forgive me, I
dont know how these things work).



--
View this message in context: 
http://spamassassin.1065346.n5.nabble.com/Spamassassin-default-SHORT-URI-list-obsolete-outdated-tp121584.html
Sent from the SpamAssassin - Users mailing list archive at Nabble.com.

Re: Where to find DETAIL for spamassassin default RULES

[jimimaseye]

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==Change which is the
> status page for the nightly rule updates and is likely what you are
> looking for.
>
> I give it a keyword too, so I can type "ruleqa RULENAME" and it will
> replace the "%s" with whatever I type. 

As for looking up and search those nightly listings, its true I can find an
individual rule, but then I cant exactly see how to drill in to it and see
its expression or detail - I can only see a load of links showing how
effective it is in tests (its not really what I was looking for).  Am I
missing something?


REGEXP:  I dont mind having a go at reading them (I have written some
myself) but, as you know, even though some are easy and obvious sometimes it
can be like reading music - a blur of blobs, dots and squiggles that take a
lot of deciphering.  Of course, many of them rely on 'functionality' of the
plugins (which I cant say I would fully understand) and the understanding of
a RULE structure (some are easy and obvious, some are very convoluted).

(I recently developed this one from scratch:  Its an RFC2822 email address
validator:
^(?=.{1,64}@)("[^<>@\\]+"|(?!\.|.*\.(\.|@))[^<>
@\\"]+)@(\[(\d{1,3}\.){3}\d{1,3}\]|\[IPv6:(?:[A-Fa-f\d]{1,4}:){7}[A-Fa-f\d]{1,4}\]|(?=.{1,255}$)((?!-|\.|\d+($|\.))[a-zA-Z\d-]{0,62}[a-zA-Z\d])(|\.(?!-|\.|\d+($|\.))[a-zA-Z\d-]{0,62}[a-zA-Z\d]){1,126})$

Very proud of it too.  )




--
View this message in context: 
http://spamassassin.1065346.n5.nabble.com/Where-to-find-DETAIL-for-spamassassin-default-RULES-tp121218p121250.html
Sent from the SpamAssassin - Users mailing list archive at Nabble.com.

Re: Advice: why one relay evaluated and not the other

[jimimaseye]

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 
> list of
> internal addresses and I do this with them. This is the list of trusted
> addresses and I do that with them. This is how I document what I have 
> done.
> Oh, internal is a subset of trusted, I better write that down when I 
> document
> it...".
>
> And that's how complicated systems end up complicated :) 

A great explanation, Sidney, and perfect round-up.  I guess this is what 
happens with opensource software and everyone 'chipping in' with ideas.

So all is working as intended (although the 'intended' seems to be a 
little long-winded).

Once again, thanks to all.




--
View this message in context: 
http://spamassassin.1065346.n5.nabble.com/Advice-why-one-relay-evaluated-and-not-the-other-tp121145p121232.html
Sent from the SpamAssassin - Users mailing list archive at Nabble.com.

Re: Advice: why one relay evaluated and not the other

[jimimaseye]

(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 hosts are 'trusted' in your setup. Trusted in 
this case means that relay hosts on these networks are considered to 
not be potentially operated by spammers, open relays, or open proxies.//
//MXes for your domain(s) and internal relays should also be 
specified using the internal_networks setting. When there are 
'trusted' hosts that are not MXes or internal relays for your domain(s) 
they should only be specified in trusted_networks.//
//.//
//.//
//Every entry in internal_networks must appear in trusted_networks; in 
other words, internal_networks is always a subset of the trusted set./"

So that suggests I should have entered the 195.26.90.  entry in both 
trusted_networks AND internal_networks (rather than just 'internal').  
Of course, I never did this. But I dont really understand the point of 
putting it in both anyway if 'trusted' is going to mean it is not going 
to be checked (whats the benefit of stating it in internal?)

It then goes on to say
/"This value is used when checking 'dial-up' or dynamic IP address 
blocklists, in order to detect direct-to-MX spamming."/

But doing this has proven it does NOTHING (as this is what I was doing) 
as long as there was a 'trusted_networks' option with a value in it.  
And then, it would only be adhered to if the trusted was removed, at 
which point the 'internal_networks' became the "trusted" range.  And 
this confirms this:

/"If trusted_networks is not set and internal_networks is, the value of 
internal_networks will be used for this parameter."/


So to summarise:

*  'internals' MUST be also quoted in TRUSTED (this is the only thing 
that makes them exempt)
*  'internals' entries are not trusted/exempt from checking unless they 
appear either in TRUSTED or in an INTERNAL_NETWORK with no 
'trusted_network' entry in config.
*  if a 'trusted' entry section exists in config, the 'internals' 
entries are there for...??  Who knows.

CONCLUSION:  it was working as the book says (even though the book is 
not clear WHY the book says what it says).




--
View this message in context: 
http://spamassassin.1065346.n5.nabble.com/Advice-why-one-relay-evaluated-and-not-the-other-tp121145p121223.html
Sent from the SpamAssassin - Users mailing list archive at Nabble.com.

Where to find DETAIL for spamassassin default RULES

[jimimaseye]

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
being updated nightly".  And googling an individual rule does only give
something useful as long as it appeared in the old 3.3 wiki (like in the
link above). So where does one find details of new rules?

For those of use that have no idea on the behind-the-scenes workings of
spamassassin (including the development contributions, scoring evaluations
etc), could someone give me a starter please to where I can start to look or
find a page giving detail similar to the above in order I can then lookup. 
(I assume that every rule has some form of explanation to it before it gets
committed and included).  How do I find such detail (in a readable, end-user
understandable form)?  (Links to development, discussion, commits or
whatever are fine just as long as ultimately it ends up giving the rule
detail).

(Currently it seems I am just having 'to trust' whatever scores are given to
the rules, and that the rules are pertinent to every system.  And without an
explanation of the rules, it seems a little strange that we, as admins, are
allowed to then tailor the scoring of such rules (if we wish to) even though
we have no idea what the rules are in the first place).

TIA



--
View this message in context: 
http://spamassassin.1065346.n5.nabble.com/Where-to-find-DETAIL-for-spamassassin-default-RULES-tp121218.html
Sent from the SpamAssassin - Users mailing list archive at Nabble.com.

Re: Advice: why one relay evaluated and not the other

[jimimaseye]

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: 
* -0.0 SHORTCIRCUIT Not all rules were run, due to a shortcircuited rule
* -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP
*

I then confirmed this discovery be re-re-re-reading the LOCAL.CF wiki manual
which does suggest 'trusted' networks takes precedence and is a 'one or the
other' affair.  So, if a TRUSTED entry exists, and you want to add another
network ('internal' or otherwise) then it should be just added to the
TRUSTED entry as ultimately it does exactly the same thing (both get deemed
as "trusted" and bypassed with the "shortcircuit ALL_TRUSTED" option set, as
shown above).  Only without a 'trusted' entry will an 'internal' entry get
applied.

I think we have all learned something there.

Thanks to all. 





--
View this message in context: 
http://spamassassin.1065346.n5.nabble.com/Advice-why-one-relay-evaluated-and-not-the-other-tp121145p121217.html
Sent from the SpamAssassin - Users mailing list archive at Nabble.com.

Re: Advice: why one relay evaluated and not the other

[jimimaseye]

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-tp121145p121211.html
Sent from the SpamAssassin - Users mailing list archive at Nabble.com.

Re: SA cannot block messages with attached zip

[jimimaseye]

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 wrote:
> 
> *3. Is the list of file extensions on the Foxhole page complete?
>   http://sanesecurity.com/foxhole-databases/
> The page is missing the following (and perhaps others):
>   .acm
>   .ax
>   .dll
>   .drv
>   .efi
>   .mui
>   .ocx
>   .tsp
> I verified that all of those actually occur and are executable
> on a Windows7 machine.





--
View this message in context: 
http://spamassassin.1065346.n5.nabble.com/SA-cannot-block-messages-with-attached-zip-tp120785p121205.html
Sent from the SpamAssassin - Users mailing list archive at Nabble.com.

Re: Advice: why one relay evaluated and not the other

[jimimaseye]

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 over-riding your internal_networks settings.
>
There is no 'override' - I am editing the single and only LOCAL.CF file 
in use.  I have proven that changes to this file are being adhered to in 
that if I add the TRUSTED_NETWORK options, then they all get adhered to 
accordingly.  I detailed my LOCAL.CF file earlier in the thread showing 
the contents (and I am not knowledgable enough to have ever even thought 
about veering in to anything else other than this LOCAL.CF - so there is 
zero chance of me ever entering something else that overrides it 
anywhere else).


> Try running SA with the '--debug' option to see the explicit list of
> config files that it is reading. Make sure that it's reading yours and
> look at the ones that come after yours to make sure that none of them
> have a "clear_internal_networks" directive.
> Be sure the user/environment that you test in is the same that is used 
> during
> the processing of messages.
>
> Silly question, is some meta-framework involved in your system (EG 
> amavis,
> etc..)
>
no, nothing.





--
View this message in context: 
http://spamassassin.1065346.n5.nabble.com/Advice-why-one-relay-evaluated-and-not-the-other-tp121145p121201.html
Sent from the SpamAssassin - Users mailing list archive at Nabble.com.

Re: Advice: why one relay evaluated and not the other

[jimimaseye]

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 it e.g. via pop3.
>
Mathaus, as this thread has shown, can you explain why adding this range 
as an internal network hasnt made a difference (and it is still being 
checked)?

>
> 
> If you reply to this email, your message will be added to the 
> discussion below:
> http://spamassassin.1065346.n5.nabble.com/Advice-why-one-relay-evaluated-and-not-the-other-tp121145p121189.html
>  
>
> To unsubscribe from Advice: why one relay evaluated and not the other, 
> click here 
> .
> NAML 
> 
>  
>





--
View this message in context: 
http://spamassassin.1065346.n5.nabble.com/Advice-why-one-relay-evaluated-and-not-the-other-tp121145p121191.html
Sent from the SpamAssassin - Users mailing list archive at Nabble.com.

Re: Advice: why one relay evaluated and not the other

[jimimaseye]

I did also test the TRUSTED_NETWORKS option as well (note:  I tried 
"trusted" and "internal" network options before resorting to this 
maillist for advice).

It results in:

X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on mailserver
X-Spam-Level:
X-Spam-Status: No, score=-1.0 required=3.0 tests=ALL_TRUSTED,HTML_MESSAGE
 autolearn=unavailable autolearn_force=no version=3.4.0
X-Spam-Report:
 * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP
 *  0.0 HTML_MESSAGE BODY: HTML included in message
 *
X-Spam-Relays-Untrusted:
X-Spam-Relays-External:
X-hMailServer-ExternalAccount: POPdaily
Return-Path: <char...@xxidlan.net>
Received: from mailin3.myhost.net (mailin3.myhost.net [195.26.90.113]) 
(authenticated
  user=sylves...@mydomain.net bits=0) by ms7.myhost.net (Cyrus 
v2.4.16-Kolab-2.4.16-1.el6)
  with LMTPSA (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 
bits=256/256
  verify=YES); Tue, 07 Jun 2016 13:31:04 +0100
X-Sieve: CMU Sieve 2.4
Received: from mailsub2.myhost.net ([195.26.90.72]) by 
mailin3.myhost.net with
  esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.85) 
(envelope-from <char...@xxidlan.net>)
  id 1bAG9w-0001Sw-2s for sylves...@mydomain.net; Tue, 07 Jun 2016 13:31:04
  +0100
Received: from [2.25.50.35] (helo=[192.168.1.249]) by 
mailsub2.myhost.net with
  esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.85) (envelope-from 
<char...@xxidlan.net>)
  id 1bAG9r-0002wq-Oo; Tue, 07 Jun 2016 13:31:03 +0100
From: Charlie Cridlan <char...@xxidlan.net>
Mime-Version: 1.0 (Apple Message framework v1085)
Content-Type: multipart/alternative; boundary=Apple-Mail-32--483328467
Subject: [SPAM] Fwd: [SPAM] from charlie re white matt vinyl
Date: Tue, 7 Jun 2016 13:30:59 +0100


But it was from seeing this that I was still left wondering why it didnt 
go further down the received headers to the next hop and do a Spamhaus 
test on [2.25.50.35] just as it was tested and found to be on Spamhaus 
by my MTA.

Maybe its my inexperience/novice status.  Is it because it is seen as 
being the first/sending client?  (Suppose so).  And therefore the only 
'relay' in the chain is the 2nd one?

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 their own servers (doing 
> their
> > own teats no doubt).  Plus they dont have just the one address - an
> > incoming emial can land at any of several servers (load balancing).  I
> > dont know the EXACT range of addresses they use but I know they are all
> > within 195.26.90.x range (hence the cross-the-board approach to cover
> > all eventualities).
>
>
> Try them as trusted_networks instead. From what you describe they're not
> what I would classify as internal, a third party manages them. You trust
> that third party so trusted_networks is fine, but internal_networks is
> more for... well, internal networks.
>
> But given you've proved that SA is still viewing that rely as both
> external and untrusted it comes down to tuning your trust path:
> https://wiki.apache.org/spamassassin/TrustPath - don't forget to restart
> spamd/however you call SA. You've basically narrowed it down to either
> using old config, using a different config, or a typo in your config. But
> it's definitely trust path related.





--
View this message in context: 
http://spamassassin.1065346.n5.nabble.com/Advice-why-one-relay-evaluated-and-not-the-other-tp121145p121185.html
Sent from the SpamAssassin - Users mailing list archive at Nabble.com.

Re: Advice: why one relay evaluated and not the other

[jimimaseye]

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: Apple Mail (2.1085)
> > X-hMailServer-Spam: YES
> > X-hMailServer-Reason-1: Rejected by Spamhaus. - (Score: 5)
> > X-hMailServer-Reason-Score: 5
>
> Please make sure that hMailServer isn't bouncing these, i.e.
> sending in a rejection message back to the sender.
>
Dont worry, they are not.


> Did you restart spamd?
>

Effectively yes (but no not really).   I am using commandline scanner 
whilst doing the tests so the LOCAL.CF is being loaded each time I run 
the test.  When it is all working then I will restart my spamd daemon to 
take effect for all incoming mail.  Proof that its working:  when I 
added the "add_header all Relays-Untrusted" entries (at the same time as 
the internal_network entry) they immediately appeared in the spam report.






--
View this message in context: 
http://spamassassin.1065346.n5.nabble.com/Advice-why-one-relay-evaluated-and-not-the-other-tp121145p121183.html
Sent from the SpamAssassin - Users mailing list archive at Nabble.com.

Re: Advice: why one relay evaluated and not the other

[jimimaseye]

Hi Kevin

I have entered the internal_network address as

internal_networks 195.26.90/24

and even

internal_networks 195.26.90.72


and it never made a difference.  Very strange.

X-Spam-Status: No, score=-1.3 required=3.0 tests=HTML_MESSAGE,
KHOP_RCVD_UNTRUST,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL,
 RCVD_IN_MSPIKE_H2 autolearn=unavailable autolearn_force=no 
version=3.4.0
X-Spam-Report:
 * -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at 
http://www.dnswl.org/, low
 *  trust
 *  [195.26.90.72 listed in list.dnswl.org]
 * -0.1 RCVD_IN_HOSTKARMA_W RBL: HostKarma: relay in white list 
(first pass)
 *  [195.26.90.72 listed in hostkarma.junkemailfilter.net]
 * -0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2)
 *  [195.26.90.72 listed in wl.mailspike.co]
 *  0.0 HTML_MESSAGE BODY: HTML included in message
 * -1.0 RCVD_IN_HOSTKARMA_WL RBL: HostKarma: unique whitelisted
 *  0.5 KHOP_RCVD_UNTRUST DNS-whitelisted sender is not verified
 *
X-Spam-Relays-Untrusted: [ ip=195.26.90.72 rdns=mailsub2.myhost.net
 helo=mailsub2.myhost.net by=mailin3.myhost.net ident=
 envfrom=char...@xxidlan.net intl=0 id=1bAG9w-0001Sw-2s 
auth= msa=0 ] [
 ip=2.25.50.35 rdns= helo=!192.168.1.249! by=mailsub2.myhost.net ident=
 envfrom=char...@xxidlan.net intl=0 id=1bAG9r-0002wq-Oo 
auth=esmtpsa
 msa=0 ]
X-Spam-Relays-External: [ ip=195.26.90.72 rdns=mailsub2.myhost.net
 helo=mailsub2.myhost.net by=mailin3.myhost.net ident=
 envfrom=char...@xxidlan.net intl=0 id=1bAG9w-0001Sw-2s 
auth= msa=0 ] [
 ip=2.25.50.35 rdns= helo=!192.168.1.249! by=mailsub2.myhost.net ident=
 envfrom=char...@xxidlan.net intl=0 id=1bAG9r-0002wq-Oo 
auth=esmtpsa
 msa=0 ]




Regarding the range:  the range belongs to our mail host provider who 
receive the emails then pass them amongst their own servers (doing their 
own teats no doubt).  Plus they dont have just the one address - an 
incoming emial can land at any of several servers (load balancing).  I 
dont know the EXACT range of addresses they use but I know they are all 
within 195.26.90.x range (hence the cross-the-board approach to cover 
all eventualities).

So, still scratching my head.

All help appreciated.


On 08/06/2016 14:22, Kevin Golding-2 [via SpamAssassin] wrote:
> On Wed, 08 Jun 2016 13:07: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
>
> That said, do you really need the whole block?
>
> You could just use 195.26.90.72 and 195.26.90.113 by the look of it. Even
> if you control the whole block presumably only a limited number of hosts
> should be relaying?
>





--
View this message in context: 
http://spamassassin.1065346.n5.nabble.com/Advice-why-one-relay-evaluated-and-not-the-other-tp121145p121180.html
Sent from the SpamAssassin - Users mailing list archive at Nabble.com.

Re: Advice: why one relay evaluated and not the other

[jimimaseye]

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 config shows, not set at all. You  
> set that correctly in your MTA but SA won't pick up on that so you need to  
> add:
> 
> 
> internal_networks 195.26.90.
> 
> 
> You may also want to try the following in your local.cf:
> 
> add_header all Relays-Untrusted _RELAYSUNTRUSTED_
> add_header all Relays-External _RELAYSEXTERNAL_

Thanks for your reply Kevin.

You explanation of why the most recent relay is ignored makes sense, thanks
for that.

I did try adding the "internal_networks 195.26.90. "  option to my LOCAL.CF
before, and in fact I have just tried it again based on your advice, but it
doesnt make any difference.  Here are the headers with

* internal_networks 195.26.90.* 
and
*add_header all Relays-Untrusted _RELAYSUNTRUSTED_
add_header all Relays-External _RELAYSEXTERNAL_ *

in place my local.cf:


Return-Path: char...@xxidlan.net
X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on mailserver
X-Spam-Level: 
X-Spam-Status: No, score=-1.3 required=3.0 tests=HTML_MESSAGE,

KHOP_RCVD_UNTRUST,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL,
RCVD_IN_MSPIKE_H2 autolearn=unavailable autolearn_force=no version=3.4.0
X-Spam-Report: 
* -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, 
low
*  trust
*  [195.26.90.72 listed in list.dnswl.org]
* -0.1 RCVD_IN_HOSTKARMA_W RBL: HostKarma: relay in white list (first 
pass)
*  [195.26.90.72 listed in hostkarma.junkemailfilter.net]
* -0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2)
*  [195.26.90.72 listed in wl.mailspike.co]
*  0.0 HTML_MESSAGE BODY: HTML included in message
* -1.0 RCVD_IN_HOSTKARMA_WL RBL: HostKarma: unique whitelisted
*  0.5 KHOP_RCVD_UNTRUST DNS-whitelisted sender is not verified
*
X-Spam-Relays-Untrusted: [ ip=195.26.90.72 rdns=mailsub2.myhost.net
helo=mailsub2.myhost.net by=mailin3.myhost.net ident=
envfrom=char...@xxidlan.net intl=0 id=1bAG9w-0001Sw-2s auth= 
msa=0
] [
ip=2.25.50.35 rdns= helo=!192.168.1.249! by=mailsub2.myhost.net ident=
envfrom=char...@xxidlan.net intl=0 id=1bAG9r-0002wq-Oo 
auth=esmtpsa
msa=0 ]
X-Spam-Relays-External: [ ip=195.26.90.72 rdns=mailsub2.myhost.net
helo=mailsub2.myhost.net by=mailin3.myhost.net ident=
envfrom=char...@xxidlan.net intl=0 id=1bAG9w-0001Sw-2s auth= 
msa=0
] [
ip=2.25.50.35 rdns= helo=!192.168.1.249! by=mailsub2.myhost.net ident=
envfrom=char...@xxidlan.net intl=0 id=1bAG9r-0002wq-Oo 
auth=esmtpsa
msa=0 ]
X-hMailServer-ExternalAccount: POPdaily
Return-Path: 
Received: from mailin3.myhost.net (mailin3.myhost.net [195.26.90.113])
(authenticated
 user=sylves...@mydomain.net bits=0) by ms7.myhost.net (Cyrus
v2.4.16-Kolab-2.4.16-1.el6)
 with LMTPSA (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384
bits=256/256
 verify=YES); Tue, 07 Jun 2016 13:31:04 +0100
X-Sieve: CMU Sieve 2.4
Received: from mailsub2.myhost.net ([195.26.90.72]) by mailin3.myhost.net
with
 esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.85) (envelope-from
)
 id 1bAG9w-0001Sw-2s for sylves...@mydomain.net; Tue, 07 Jun 2016 13:31:04
 +0100
Received: from [2.25.50.35] (helo=[192.168.1.249]) by mailsub2.myhost.net
with
 esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.85) (envelope-from
)
 id 1bAG9r-0002wq-Oo; Tue, 07 Jun 2016 13:31:03 +0100
From: Charlie Cridlan 
Mime-Version: 1.0 (Apple Message framework v1085)
Content-Type: multipart/alternative; boundary=Apple-Mail-32--483328467
Subject: [SPAM] from charlie re white matt vinyl
Date: Tue, 7 Jun 2016 13:30:59 +0100
References: <57554b88.1040...@mydomain.net>
Cc:  sylves...@mydomain.net
To: Liz 
Message-Id: 
X-Mailer: Apple Mail (2.1085)
X-hMailServer-Spam: YES
X-hMailServer-Reason-1: Rejected by Spamhaus. - (Score: 5)
X-hMailServer-Reason-Score: 5



You can see that it is still evaluating 195.26.90.72 and considers it
untrusted/external despite it being within the 'internal network' subnet.

Am I missing something?  Could you advise please.

Many thanks





--
View this message in context: 
http://spamassassin.1065346.n5.nabble.com/Advice-why-one-relay-evaluated-and-not-the-other-tp121145p121176.html
Sent from the SpamAssassin - Users mailing list archive at Nabble.com.

Advice: why one relay evaluated and not the other

[jimimaseye]

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 dealt
with accordingly based on the scores.

All normal stuff.
*
ENVIRONMENT*

The EXTERNAL HOST mail server is in on a subnet 195.26.90.xxx, and as such I
have marked this as an 'internal relay' in my MTA.  This is so that when it
does its internal antispam checks, it then ignores the received headers that
fit this range and does its DNSBL checks on addresses that are not in this
range.

All good so far.

*THE PROBLEM IN DETAIL*


I have some confusion.  See these headers to this email:



X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on mailserver
X-Spam-Level:
X-Spam-Status: No, score=-4.2 required=3.0 tests=BAYES_00,HTML_MESSAGE,
KHOP_RCVD_UNTRUST,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL,
 RCVD_IN_MSPIKE_H2 autolearn=ham autolearn_force=no version=3.4.0
X-Spam-Report:
 * -0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2)
 *  [195.26.90.72 listed in wl.mailspike.co]
 * -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low
 *  trust
 *  [195.26.90.72 listed in list.dnswl.org]
 * -0.1 RCVD_IN_HOSTKARMA_W RBL: HostKarma: relay in white list (first pass)
 *  [195.26.90.72 listed in hostkarma.junkemailfilter.co]
 * -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%
 *  [score: 0.] *  0.0 HTML_MESSAGE BODY: HTML included in message
 * -2.0 RCVD_IN_HOSTKARMA_WL RBL: HostKarma: unique whitelisted
 *  0.5 KHOP_RCVD_UNTRUST DNS-whitelisted sender is not verified
 *
X-hMailServer-ExternalAccount: POPdaily
Return-Path: 

Received: from mailin3.myhost.co (mailin3.myhost.co [195.26.90.113])
(authenticated
 user=sylves...@mydomain.co bits=0) by ms7.myhost.co (Cyrus
v2.4.16-Kolab-2.4.16-1.el6)
 with LMTPSA (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384
bits=256/256
 verify=YES); Tue, 07 Jun 2016 13:31:04 +0100
X-Sieve: CMU Sieve 2.4

Received: from mailsub2.myhost.co ([195.26.90.72]) by mailin3.myhost.co with
 esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.85) (envelope-from
)
 id 1bAG9w-0001Sw-2s for sylves...@mydomain.co; Tue, 07 Jun 2016 13:31:04
 +0100

Received: from [2.25.50.35] (helo=[192.168.1.249]) by mailsub2.myhost.co
with
 esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.85) (envelope-from
)
 id 1bAG9r-0002wq-Oo; Tue, 07 Jun 2016 13:31:03 +0100

From: X 
Mime-Version: 1.0 (Apple Message framework v1085)
Content-Type: multipart/alternative; boundary=Apple-Mail-32--483328467
Subject: [SPAM] re white matt vinyl
Date: Tue, 7 Jun 2016 13:30:59 +0100
References: <57554b88.1040...@mydomain.co>* -0.0 RCVD_IN_MSPIKE_H2 RBL:
Average reputation (+2)
Date: Tue, 7 Jun 2016 13:30:59 +0100
References: <57554b88.1040...@mydomain.net>
To: Liz Jones 
Message-Id: 
X-Mailer: Apple Mail (2.1085)
X-hMailServer-Spam: YES
X-hMailServer-Reason-1: Rejected by Spamhaus. - (Score: 5)
X-hMailServer-Reason-Score: 5


Now you should note that the last 3 headers show that my MTA's internal spam
checks show that the email is deemed suspect ("Rejected by Spamhaus") as
[2.25.50.35] appears in Spamhaus blacklist.  (Check and you wll see its in
the PBL list).  (My MTA doesnt say anything about the addresses 195.26.90.72
or 195.26.90.113 because, as I said, it has been advised this range is
trusted and bypasses them).

HOWEVER, and here are my questions please:

1,  You can see that Spamassassin considered and evaluated the IP address
195.26.90.72 (as reported in its report).  Now this is the SECOND received
header in the list.  And yet it doesnt evaluate the most recent (first on
list) [195.26.90.113] which is also from the same range (only the final
numbers differ).  Why is this? Why one and not the other?  (I note that in
all cases this final/most recent relay is never checked by SA actually.  Not
a problem, very glad of it, but dont know why).

2,  I also note that it didnt say anything about [2.25.50.35].  (It should
also have found it in the Spamhaus BL just like the MTA did).

FYI:  There is nothing in my SA config that would affect thesem decisions. 
This is the entirety  of my conf file:


 report_safe 0
 add_header all Report _REPORT_ *
 score DRUGS_ERECTILE 10
 dns_available yes

 rewrite_header Subject [_HITS_]
 trusted_networks 192.168.0.
 required_score 3.0

ifplugin Mail::SpamAssassin::Plugin::Shortcircuit

 shortcircuit USER_IN_WHITELIST   on
 shortcircuit USER_IN_DEF_WHITELIST   on
 shortcircuit ALL_TRUSTED on

endif # Mail::SpamAssassin::Plugin::Shortcircuit



*SUMMARY*

Any help to explain why ony the 2nd address was evaluated and not the