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.
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_netwo
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 t
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.
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:
>
> i
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
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
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 com
> 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://spamassass
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 dom
ly 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 he
On Wed, 08 Jun 2016 13:49:17 +0100, jimimaseye
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 an
On Wed, 08 Jun 2016 13:59:26 +0100
Kevin Golding wrote:
> On Wed, 08 Jun 2016 13:49:17 +0100, jimimaseye
> 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). P
> > 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. P
estart
> 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.
t 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://spamassas
On Wed, 08 Jun 2016 13:49:17 +0100, jimimaseye
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 a
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. -
massassin.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.
On Wed, 08 Jun 2016 13:07:14 +0100, jimimaseye
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.
ew 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.
On Wed, 08 Jun 2016 07:22:19 +0100, jimimaseye
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
amassassin.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.
23 matches
Mail list logo