You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by jimimaseye <gr...@yahoo.com> on 2016/06/08 06:22:19 UTC
Advice: why one relay evaluated and not the other
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.0000] * 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: <ch...@chaxxxxxridlan.co>
Received: from mailin3.myhost.co (mailin3.myhost.co [195.26.90.113])
(authenticated
user=sylvester@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
<ch...@chaxxxxxridlan.co>)
id 1bAG9w-0001Sw-2s for sylvester@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
<ch...@chaxxxxxridlan.co>)
id 1bAG9r-0002wq-Oo; Tue, 07 Jun 2016 13:31:03 +0100
From: Xxxxxxxxx <ch...@chaxxxxxridlan.co>
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: <57...@mydomain.co>* -0.0 RCVD_IN_MSPIKE_H2 RBL:
Average reputation (+2)
Date: Tue, 7 Jun 2016 13:30:59 +0100
References: <57...@mydomain.net>
To: Liz Jones <li...@numbers-ltd.net>
Message-Id: <B4...@chaxxxxxxdlan.net>
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 first,
and why the 3rd on was not correctly found in Spamhaus would be appreciated.
Thanks
(I hope I havent managed to post this twice. Im still trying to understand
how this mailing list operates).
--
View this message in context: http://spamassassin.1065346.n5.nabble.com/Advice-why-one-relay-evaluated-and-not-the-other-tp121145.html
Sent from the SpamAssassin - Users mailing list archive at Nabble.com.
Re: Advice: why one relay evaluated and not the other
Posted by jimimaseye <gr...@yahoo.com>.
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: <ch...@xxxxxxxxxxidlan.net>
Received: from mailin3.myhost.net (mailin3.myhost.net [195.26.90.113])
(authenticated
user=sylvester@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 <ch...@xxxxxxxxxxidlan.net>)
id 1bAG9w-0001Sw-2s for sylvester@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
<ch...@xxxxxxxxxxidlan.net>)
id 1bAG9r-0002wq-Oo; Tue, 07 Jun 2016 13:31:03 +0100
From: Charlie Cridlan <ch...@xxxxxxxxxxidlan.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] </user/SendEmail.jtp?type=node&node=121182&i=0>> 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
Posted by jimimaseye <gr...@yahoo.com>.
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
Posted by Sidney Markowitz <si...@sidney.com>.
jimimaseye wrote on 10/06/16 1:50 AM:
> CONCLUSION: it was working as the book says (even though the book is not
> clear WHY the book says what it says).
It's been a very long while since I worked with this code and I have to kind
of twist my mind up funny to keep it in my head all at once, but this is how I
remember how it came to be:
You get an email that contains a chain of Received headers, purporting to tell
you the path the email took going from each host to the next. Each header
tells you that the host at a particular ip address claims that it received the
mail from some other certain ip address.
The top-most Received headers will have been inserted by machines in your
internal network. You can rely on those headers being accurate. However those
headers tell you nothing about the origin of the email.
The Received header that is the bottom internal one will tell you where the
mail actually came from. You can believe that you know the real ip address of
the host outside your internal network that sent you the mail because it
appears in the Received header that is generated by a machine in your internal
network. Typically that will be one of your MX servers telling you what
machine sent it the mail, which is why the MX servers should be listed as
"internal". If the ip address that sent you the mail is a known spammer, that
can be caught this way.
You also know that you can't trust any Received headers below that one because
they can be totally fake.
Unless... What if you get mail, for example, sent to a gmail address which
forwards to your own domain address? Then the bottom Received header in your
internal list will show that the mail was received from a known Google mail ip
address. If you put the Google addresses on the trusted list, you can know
that the Received headers that claim to represent the travels of the mail
through Google's servers to yours are not faked. That will lead you to the
bottom-most trusted Received header which will tell you the ip address that
sent the mail to your gmail address. And that's the ip address that you can
check for being a known spammer, and it is the Received headers below that
which might be faked.
There are some differences in what can be reasoned about internal address vs
trusted external addresses. I don't recall the details, but I can see how for
example the internal ones can include addresses like 10.0.0.5 which are not
legal on the outside Internet. If you see such an address in a Received header
that is below the internal ones, then the address tells you nothing.
tl;dr Internal addresses identify the machines in your local mail delivery
setup. Trusted address identify machines that will not spoof Received headers.
Different reasoning can applied to the two. Together they tell you which
Received headers to ignore because they may be completely fake.
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 :)
Sidney
Re: Advice: why one relay evaluated and not the other
Posted by RW <rw...@googlemail.com>.
On Thu, 9 Jun 2016 06:50:55 -0700 (MST)
jimimaseye wrote:
> (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 host</b>s on these networks are considered
> to not be potentially operated by spammers, open relays, or open
> proxies.// // MXes for your domain(s) and <b>internal relays
> should also be specified using the internal_networks setting</b>.
> 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').
As I said, if you only set one, the other is implied to be the same.
> 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?)
trusted means that a server is trusted not to be spammer controlled, so
you can rely on it not to forge headers. The edge of the internal
network is used to find the relevant MX handover.
In most cases SA can work out the internal/trusted networks for itself,
where it can't it's usually not necessary, or advisable, to
extent the trusted network beyond the internal network. It's only
needed in some corner-cases involving multiple networks.
Re: Advice: why one relay evaluated and not the other
Posted by jimimaseye <gr...@yahoo.com>.
(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 host</b>s on these networks are considered to
not be potentially operated by spammers, open relays, or open proxies.//
// MXes for your domain(s) and <b>internal relays should also be
specified using the internal_networks setting</b>. 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.
Re: Advice: why one relay evaluated and not the other
Posted by RW <rw...@googlemail.com>.
On Thu, 9 Jun 2016 02:54:34 -0700 (MST)
jimimaseye wrote:
> 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.
It shouldn't matter whether whether you specified trusted_networks as
long as it contains all of the relevant addresses seen in the headers.
It's now working, but this doesn't explain why it wasn't working
before.
> 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
The wiki isn't the manual:
https://spamassassin.apache.org/full/3.4.x/doc/Mail_SpamAssassin_Conf.html
see also
http://spamassassin.apache.org/full/3.4.x/doc/
> 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.
No that's wrong. Everything that's in internal has to be in trusted.
But if you define only trusted or only internal, they are assumed to be
the same.
Re: Advice: why one relay evaluated and not the other
Posted by jimimaseye <gr...@yahoo.com>.
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
Posted by jimimaseye <gr...@yahoo.com>.
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: Advice: why one relay evaluated and not the other
Posted by RW <rw...@googlemail.com>.
On Wed, 8 Jun 2016 12:49:03 -0700 (MST)
jimimaseye wrote:
> On 08/06/2016 21:26, David B Funk [via SpamAssassin] wrote:
> > 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.
What people may have missed is that this is a Windows server running
the Jam Software version of SpamAssassin.
Re: Advice: why one relay evaluated and not the other
Posted by jimimaseye <gr...@yahoo.com>.
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
Posted by David B Funk <db...@engineering.uiowa.edu>.
On Wed, 8 Jun 2016, jimimaseye wrote:
>
>
> 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)?
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.
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..)
--
Dave Funk University of Iowa
<dbfunk (at) engineering.uiowa.edu> College of Engineering
319/335-5751 FAX: 319/384-0549 1256 Seamans Center
Sys_admin/Postmaster/cell_admin Iowa City, IA 52242-1527
#include <std_disclaimer.h>
Better is not better, 'standard' is better. B{
Re: Advice: why one relay evaluated and not the other
Posted by jimimaseye <gr...@yahoo.com>.
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
> <http://spamassassin.1065346.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=121145&code=Z3JvYWNobWFpbC1zdG9wc3BhbW1pbmdtZUB5YWhvby5jb218MTIxMTQ1fC0xMzQ1NzE0OTc5>.
> NAML
> <http://spamassassin.1065346.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.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
Posted by Matus UHLAR - fantomas <uh...@fantomas.sk>.
>On Wed, 08 Jun 2016 13:49:17 +0100, jimimaseye
><gr...@yahoo.com> 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).
On 08.06.16 13:59, Kevin Golding wrote:
>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.
note that if a server acts as your MX, it should be listed in
internal_networks, no matter if other company manages it.
checks like SPF dynamic IP are done on internal network boundary, not
including MX relays causes troubles
That applies for backup MX servers for your domain, or, even primary MX if
you fetch mail from it e.g. via pop3.
(yes, I know it's mentioned in the wiki, but I find it important ennough to
mention it here)
>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.
--
Matus UHLAR - fantomas, uhlar@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.
Due to unexpected conditions Windows 2000 will be released
in first quarter of year 1901
Re: Advice: why one relay evaluated and not the other
Posted by RW <rw...@googlemail.com>.
On Wed, 08 Jun 2016 13:59:26 +0100
Kevin Golding wrote:
> On Wed, 08 Jun 2016 13:49:17 +0100, jimimaseye
> <gr...@yahoo.com> 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.
Putting servers like this into internal_networks is almost always the
right thing to do. Putting them into trusted_networks reduces
effectiveness and should be done as a last resort.
It's needed only if receiving a significant amount of mail that's
submitted by mail clients into that network, and that mail has no
authentication recorded in the Received headers.
Re: Advice: why one relay evaluated and not the other
Posted by Kevin Golding <kp...@caomhin.org>.
On Wed, 08 Jun 2016 13:49:17 +0100, jimimaseye
<gr...@yahoo.com> 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.
Re: Advice: why one relay evaluated and not the other
Posted by jimimaseye <gr...@yahoo.com>.
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=charlie@xxxxxxxxxxidlan.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=charlie@xxxxxxxxxxidlan.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=charlie@xxxxxxxxxxidlan.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=charlie@xxxxxxxxxxidlan.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
Posted by Kevin Golding <kp...@caomhin.org>.
On Wed, 08 Jun 2016 13:07:14 +0100, jimimaseye
<gr...@yahoo.com> wrote:
> 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.*
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?
Re: Advice: why one relay evaluated and not the other
Posted by Matthias Leisi <ma...@leisi.net>.
> > 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.
You’re calling the spamassassin binary? Are you running it as the same user that spamd would run as? What does spamassassin -d tell you about (which/whether) local.cf is loaded?
— Matthias
Re: Advice: why one relay evaluated and not the other
Posted by jimimaseye <gr...@yahoo.com>.
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
Posted by RW <rw...@googlemail.com>.
On Wed, 8 Jun 2016 05:07:14 -0700 (MST)
jimimaseye 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.
> 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.
> 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.
Did you restart spamd?
Re: Advice: why one relay evaluated and not the other
Posted by jimimaseye <gr...@yahoo.com>.
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: charlie@xxxxxxxxxxidlan.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=charlie@xxxxxxxxxxidlan.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=charlie@xxxxxxxxxxidlan.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=charlie@xxxxxxxxxxidlan.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=charlie@xxxxxxxxxxidlan.net intl=0 id=1bAG9r-0002wq-Oo auth=esmtpsa
msa=0 ]
X-hMailServer-ExternalAccount: POPdaily
Return-Path: <ch...@xxxxxxxxxxidlan.net>
Received: from mailin3.myhost.net (mailin3.myhost.net [195.26.90.113])
(authenticated
user=sylvester@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
<ch...@xxxxxxxxxxidlan.net>)
id 1bAG9w-0001Sw-2s for sylvester@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
<ch...@xxxxxxxxxxidlan.net>)
id 1bAG9r-0002wq-Oo; Tue, 07 Jun 2016 13:31:03 +0100
From: Charlie Cridlan <ch...@xxxxxxxxxxidlan.net>
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: <57...@mydomain.net>
Cc: sylvester@mydomain.net
To: Liz <li...@net>
Message-Id: <B4...@xxxxxxxxxxidlan.net>
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.
Re: Advice: why one relay evaluated and not the other
Posted by Kevin Golding <kp...@caomhin.org>.
On Wed, 08 Jun 2016 07:22:19 +0100, jimimaseye
<gr...@yahoo.com> wrote:
> 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).
This is because of how you're retrieving your mail - that header states it
is an authenticated user and therefore SA automatically treats that relay
as trusted.
> 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).
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_
They'll add headers doing pretty much what they say on the tin - listing
external relays and untrusted relays. They can be very helpful for
debugging things like this. They should tell you pretty much exactly what
I just did.