Re: trusted_networks and internal_networks confusion
On Sat, 17 Dec 2016 20:51:01 +0100 Marcus Schopen wrote: > > SpamAssassin usually deals with this problem by looking for > > authentication in the header, but that's not recorded here. > > There is no auth hint in the header when using the submission server. > > Received: from [192.168.178.25] ([my dynamic IP]) by > smtp-out.myoffice.de (Oracle Communications Messaging Server > 7.0.5.37.0 64bit (built Jan 25 2016)) with ESMTPPA id > <0OIA00E6KOQ65A80@smtp-out,myoffice> for i...@test.de; > Fri, 16 Dec 2016 21:25:20 +0100 (CET) Authentication is commonly indicated by the A in "with ESMTPA". I don't know what the second P in ESMTPPA is for, but it seems to be the source of your problem.
Re: trusted_networks and internal_networks confusion
Hi, Am Samstag, den 17.12.2016, 13:17 + schrieb RW: > On Fri, 16 Dec 2016 22:41:49 +0100 > Marcus Schopen wrote: > > > > The problem is, that smtp-out.myoffice.de is also a submission server > > for dialup clients. Headers from to to down: > > > > Received: from smtp-out.myoffice.de by MY_SERVER_IP > > Received: from dialup-client-IP by smtp-out.myoffice.de > > SpamAssassin usually deals with this problem by looking for > authentication in the header, but that's not recorded here. There is no auth hint in the header when using the submission server. Received: from [192.168.178.25] ([my dynamic IP]) by smtp-out.myoffice.de (Oracle Communications Messaging Server 7.0.5.37.0 64bit (built Jan 25 2016)) with ESMTPPA id <0OIA00E6KOQ65A80@smtp-out,myoffice> for i...@test.de; Fri, 16 Dec 2016 21:25:20 +0100 (CET) I think they manipulate the header or have a proxy, because the smtp host in my mailclient is smtp.myoffice.de (with a another IP) and not smtp-out.myoffice.de. But smtp-out.myoffice.de comes up as the first connecting host for the mail client. > I think your best option is to leave it in internal_networks and write > a custom rule to take some points off when it's submission. Good idea, something like if smtp-out.myoffice.de is the first trusted (header from down to top) 10 points off. How can I do that or what would you think? Ciao!
Re: trusted_networks and internal_networks confusion
On Fri, 16 Dec 2016 22:41:49 +0100 Marcus Schopen wrote: > The problem is, that smtp-out.myoffice.de is also a submission server > for dialup clients. Headers from to to down: > > Received: from smtp-out.myoffice.de by MY_SERVER_IP > Received: from dialup-client-IP by smtp-out.myoffice.de SpamAssassin usually deals with this problem by looking for authentication in the header, but that's not recorded here. I think your best option is to leave it in internal_networks and write a custom rule to take some points off when it's submission.
Re: trusted_networks and internal_networks
On Tue, July 14, 2009 21:26, Jari Fredriksson wrote: > Duh. Dumb. Arrgh! Hit! Damn. its rocket science :) -- xpoint
Re: trusted_networks and internal_networks
Jari Fredriksson a écrit : >> [snip] >> when I put your lines in my config, I only seethe >> 127.0.0.1/32 warning. >> > >>> >>> It looks like SA itself configured the trusted. > > I removed both the 127.0.0.1 AND 10/8 and this is happy again. It seems to > configure the internal networks as trusted automagically. As it should be IMO. > It may be as "it should be" for you. so it's a good default. but here, internal != trusted (strict subset), because I "trust" relays that are not under my control and which may accept mail from residential users.
Re: trusted_networks and internal_networks
> Jari Fredriksson a écrit : >> I tried with this: >> >> -(local.cf)--- >> >> internal_networks 10.0.0.0/8 >> trusted_networks 10.0.0.0/8 127.0.0.1 >> trusted_networks 212.16.98.0/24 212.16.100.0/24 >> 62.142.0.0/16 195.197.172.98 trusted_networks >> 195.74.0.0/16 213.192.189.2/24 217.30.188.0/24 >> 65.54.0.0/16 trusted_networks 83.145.211.136 >> 217.30.180.104 >> trusted_networks 64.233.183.0/24 209.85.199.0/24 >> 72.14.247.27/24 64.233.163.27 trusted_networks >> 213.157.94.92 >> >> -- >> >> Here, internal is a subset of trusted, is that how it >> should go? >> >> $ spamassassin -D --lint >> >> [7594] warn: netset: cannot include 127.0.0.1/32 as it >> has already been included > > remove 127.0.0.1/32 > >> [7594] warn: netset: cannot include 10.0.0.0/8 as it has >> already been included > > which version of SA is this? also grep for 10.0 in your > .cf files. > > when I put your lines in my config, I only seethe > 127.0.0.1/32 warning. > Case resolved. I grepped and found an additional trusted_networks in the local.cf Duh. Dumb. Arrgh! Hit! Damn.
Re: trusted_networks and internal_networks
> Jari Fredriksson a écrit : >> I tried with this: >> >> -(local.cf)--- >> >> internal_networks 10.0.0.0/8 >> trusted_networks 10.0.0.0/8 127.0.0.1 >> trusted_networks 212.16.98.0/24 212.16.100.0/24 >> 62.142.0.0/16 195.197.172.98 trusted_networks >> 195.74.0.0/16 213.192.189.2/24 217.30.188.0/24 >> 65.54.0.0/16 trusted_networks 83.145.211.136 >> 217.30.180.104 >> trusted_networks 64.233.183.0/24 209.85.199.0/24 >> 72.14.247.27/24 64.233.163.27 trusted_networks >> 213.157.94.92 >> >> -- >> >> Here, internal is a subset of trusted, is that how it >> should go? >> >> $ spamassassin -D --lint >> >> [7594] warn: netset: cannot include 127.0.0.1/32 as it >> has already been included > > remove 127.0.0.1/32 > >> [7594] warn: netset: cannot include 10.0.0.0/8 as it has >> already been included > > which version of SA is this? also grep for 10.0 in your > .cf files. > 3.2.5 from cpan. > when I put your lines in my config, I only seethe > 127.0.0.1/32 warning. > >> >> >> It looks like SA itself configured the trusted. I removed both the 127.0.0.1 AND 10/8 and this is happy again. It seems to configure the internal networks as trusted automagically. As it should be IMO.
Re: trusted_networks and internal_networks
Jari Fredriksson a écrit : > I tried with this: > > -(local.cf)--- > > internal_networks 10.0.0.0/8 > trusted_networks 10.0.0.0/8 127.0.0.1 > trusted_networks 212.16.98.0/24 212.16.100.0/24 62.142.0.0/16 195.197.172.98 > trusted_networks 195.74.0.0/16 213.192.189.2/24 217.30.188.0/24 65.54.0.0/16 > trusted_networks 83.145.211.136 217.30.180.104 > trusted_networks 64.233.183.0/24 209.85.199.0/24 72.14.247.27/24 64.233.163.27 > trusted_networks 213.157.94.92 > > -- > > Here, internal is a subset of trusted, is that how it should go? > > $ spamassassin -D --lint > > [7594] warn: netset: cannot include 127.0.0.1/32 as it has already been > included remove 127.0.0.1/32 > [7594] warn: netset: cannot include 10.0.0.0/8 as it has already been included which version of SA is this? also grep for 10.0 in your .cf files. when I put your lines in my config, I only seethe 127.0.0.1/32 warning. > > > It looks like SA itself configured the trusted. >
Re: trusted_networks and internal_networks
On Tue, July 14, 2009 14:48, Jari Fredriksson wrote: > Yeah. My LAN is using 10/8 for hysterical reasons. Is there something wrong > here? just that your source have now rfc1918 ranges hardcorded into sa, so remove your own internal/trsuted/msa for rfc1918 will solve it ps: i have not seen the cpan source, but the error you get is that problem -- xpoint
Re: trusted_networks and internal_networks
Jari Fredriksson wrote: I tried with this: -(local.cf)--- internal_networks 10.0.0.0/8 trusted_networks 10.0.0.0/8 127.0.0.1 trusted_networks 212.16.98.0/24 212.16.100.0/24 62.142.0.0/16 195.197.172.98 trusted_networks 195.74.0.0/16 213.192.189.2/24 217.30.188.0/24 65.54.0.0/16 trusted_networks 83.145.211.136 217.30.180.104 trusted_networks 64.233.183.0/24 209.85.199.0/24 72.14.247.27/24 64.233.163.27 trusted_networks 213.157.94.92 -- Here, internal is a subset of trusted, is that how it should go? $ spamassassin -D --lint [7594] warn: netset: cannot include 127.0.0.1/32 as it has already been included [7594] warn: netset: cannot include 10.0.0.0/8 as it has already been included It looks like SA itself configured the trusted. I know that you should not include 127.0.0.1 since it is always there by default (if you can't trust your own server, you have bigger problems than the SA config), but I'm not sure where the error for 10.0.0.0/8 came from. That one should not be trusted by default as far as I know. -- Bowie
Re: trusted_networks and internal_networks
> On Tue, July 14, 2009 13:25, Jari Fredriksson wrote: > >> [7594] warn: netset: cannot include 127.0.0.1/32 as it >> has already been included [7594] warn: netset: cannot >> include 10.0.0.0/8 as it has already been included It >> looks like SA itself configured the trusted. > > rfc1918 > Yeah. My LAN is using 10/8 for hysterical reasons. Is there something wrong here? > sa 3.3 ? 3.2.5 from cpan.
Re: trusted_networks and internal_networks
On Tue, July 14, 2009 13:25, Jari Fredriksson wrote: > [7594] warn: netset: cannot include 127.0.0.1/32 as it has already been > included > [7594] warn: netset: cannot include 10.0.0.0/8 as it has already been included > It looks like SA itself configured the trusted. rfc1918 sa 3.3 ? -- xpoint
Re: trusted_networks and internal_networks
> Jari Fredriksson a écrit :
>>> MrGibbage a écrit :
#ps11651.dreamhostps.com and pelorus.org
internal_networks 75.119.219.171
trusted_networks 75.119.219.171 #I think this is wrong
>>> no, it is not wrong. the documentation says:
>>>
>>> Every entry in "internal_networks" must appear in
>>> "trusted_net-
>>>
>>> works";
>>>
>>> so whenever you put an internal_network line, you should
>>> add the same line with "trusted" instead of "internal".
>>>
>>
>> If that is indeed true,
>
> As of 3.2.5, Received.pm contains this:
>
> if (!$relay->{auth} &&
> !$trusted->contains_ip($relay->{ip})) {
> $in_trusted = 0; $in_internal = 0; # if it's
> not trusted it's not internal
>
>
>}
>
> so as soon as an "untrusted" relay is found, it is
> considered as "external".
>
>> it is a BUG IMO.
>>
>
> not really a bug. just a configuration annoyance . I
> mean, since internal_networks is a subset of
> trusted_networks, then any "internal" relay should
> automatically be considered as "trusted", without the
> need to duplicate information.
>
>
>> Brain dead requirement!
>
> the requirement is "reasonable". an "internal" relay that
> wouldn't be "trusted" is irrelevant. why would you want
> to skip PBL/DUL lookup for an IP that may be forged?
I tried with this:
-(local.cf)---
internal_networks 10.0.0.0/8
trusted_networks 10.0.0.0/8 127.0.0.1
trusted_networks 212.16.98.0/24 212.16.100.0/24 62.142.0.0/16 195.197.172.98
trusted_networks 195.74.0.0/16 213.192.189.2/24 217.30.188.0/24 65.54.0.0/16
trusted_networks 83.145.211.136 217.30.180.104
trusted_networks 64.233.183.0/24 209.85.199.0/24 72.14.247.27/24 64.233.163.27
trusted_networks 213.157.94.92
--
Here, internal is a subset of trusted, is that how it should go?
$ spamassassin -D --lint
[7594] warn: netset: cannot include 127.0.0.1/32 as it has already been included
[7594] warn: netset: cannot include 10.0.0.0/8 as it has already been included
It looks like SA itself configured the trusted.
Re: trusted_networks and internal_networks
> > where did your squirrelmail go now ? I use it when I'm not sitting at home. It is up on my server, but I do not use it if I have access to my workstation. I prefer Outlook Express with OE-QuoteFix over any other IMAP client I have tested.
Re: trusted_networks and internal_networks
On Tue, July 14, 2009 00:42, mouss wrote: > the requirement is "reasonable". an "internal" relay that wouldn't be > "trusted" is irrelevant. why would you want to skip PBL/DUL lookup for > an IP that may be forged? if thats the problem the mail wont get delivered in the first place -- xpoint
Re: trusted_networks and internal_networks
On Tue, July 14, 2009 00:08, Jari Fredriksson wrote: >> so whenever you put an internal_network line, you should >> add the same line with "trusted" instead of "internal". > If that is indeed true, it is a BUG IMO. > Brain dead requirement! at least its open source so one can make a good patch to fix it i find the hardcodes of 127.0.0.1 more brain dead then the above ! back to perl problem right ?, and more works on ExtractText ? :) where did your squirrelmail go now ? -- xpoint
Re: trusted_networks and internal_networks
On Mon, July 13, 2009 23:55, mouss wrote: > so whenever you put an internal_network line, you should add the same > line with "trusted" instead of "internal". in other words, internal cant be untrusted so if you see spam with origin as internal networks ip then remove that ip as internal -- xpoint
Re: trusted_networks and internal_networks
Jari Fredriksson a écrit :
>> MrGibbage a écrit :
>>> #ps11651.dreamhostps.com and pelorus.org
>>> internal_networks 75.119.219.171
>>> trusted_networks 75.119.219.171 #I think this is wrong
>> no, it is not wrong. the documentation says:
>>
>> Every entry in "internal_networks" must appear in
>> "trusted_net-
>>
>> works";
>>
>> so whenever you put an internal_network line, you should
>> add the same line with "trusted" instead of "internal".
>>
>
> If that is indeed true,
As of 3.2.5, Received.pm contains this:
if (!$relay->{auth} && !$trusted->contains_ip($relay->{ip})) {
$in_trusted = 0;
$in_internal = 0; # if it's not trusted it's not internal
}
so as soon as an "untrusted" relay is found, it is considered as
"external".
> it is a BUG IMO.
>
not really a bug. just a configuration annoyance . I mean, since
internal_networks is a subset of trusted_networks, then any "internal"
relay should automatically be considered as "trusted", without the need
to duplicate information.
> Brain dead requirement!
the requirement is "reasonable". an "internal" relay that wouldn't be
"trusted" is irrelevant. why would you want to skip PBL/DUL lookup for
an IP that may be forged?
Re: trusted_networks and internal_networks
> MrGibbage a écrit : >> #ps11651.dreamhostps.com and pelorus.org >> internal_networks 75.119.219.171 >> trusted_networks 75.119.219.171 #I think this is wrong > > no, it is not wrong. the documentation says: > > Every entry in "internal_networks" must appear in > "trusted_net- > > works"; > > so whenever you put an internal_network line, you should > add the same line with "trusted" instead of "internal". > If that is indeed true, it is a BUG IMO. Brain dead requirement!
Re: trusted_networks and internal_networks
MrGibbage a écrit : > I have read the help pages for those two settings over and over, and I guess > I'm just not smart enough. I can't figure out what I should put for those > two settings. Can one of you give me a hand by looking at the headers from > an email? I can tell you that my SA installation is on > "ps11651.dreamhostps.com" and the way I receive email is I my email is sent > to my public email address, "s...@pelorus.org" and I have an auto-forwarder > which sends the mail to my SA box via email, at > skip-mor...@psoneonesixfiveone.dreamhostps.com (mangled here). I never > receive mail directly to skip-mor...@psoneonesixfiveone.dreamhostps.com. If > I did, it would have to be spam because they scraped the address from > somewhere. pelorus.org and ps11651.dreamhostps.com are the same box. All > the appriver stuff below is done on the sending side of my company's > exchange server. > > Anyway, maybe I got it, but these two settings seemed too important to get > wrong, so I just want to be sure. > > #ps11651.dreamhostps.com and pelorus.org > internal_networks 75.119.219.171 > trusted_networks 75.119.219.171 #I think this is wrong no, it is not wrong. the documentation says: Every entry in "internal_networks" must appear in "trusted_net- works"; so whenever you put an internal_network line, you should add the same line with "trusted" instead of "internal". > > So is the idea that I could add more trusted_networks to the list, sort of > like a whitelist. Perhaps adding my work ip addresses below? Isn't that > trusted_networks setting above saying "**ALL** mail is trusted to not be > spam since **ALL** mail comes in on that IP address? And what about the > "Received: from homiemail-mx7.g.dreamhost.com > (balanced.mail.policyd.dreamhost.com [208.97.132.119])"? I have checked and > I do receive all mail from one of 208.97.132.* Should that be on my > internal_networks? > [snip] here, trusted mostly means the relay does not forge Received headers. it can relay spam, but it is not controlled by spammers (directly or via trojans/open proxies/...). to summarise: for those relays that you trust not to be operated by spammers (directly or not): - if they receive mail from "residential/dynamic" IPs (without authentication), then list them in trusted_networks only - else, list them in both internal_networks and trusted_networks If this is too theoritical, consider the practical side: When SA looks up PBL, SORBS_DUL, ..., it will not look up IPs listed in internal_networks. in general, your own relays will be listed in both internal_networks and trusted_networks. but if you have a forwarder that is not under your control, and that may be used to relay mail for "residential" IPs, then you don't want to put it in internal_networks (otherwise, mail from the residential IPs may be caught by PBL, SORBS_DUL, ... evethough it is relayedvia a smarthost, as is generally recommended).
Re: trusted_networks and internal_networks
Wow, I had a feeling I was opening a can of worms here. This is one area where I really feel the SA documentation could benefit by having some real world examples. Right now I am just going with the one internal_networks set to the ip of my SA server. I'm not setting any trusted_networks. I figure there's no harm in not trusting anyone, right? Just a few extra CPU cycles while SA checks out all the IP addresses in the email. Or is there more impact than just that? Skip RW-15 wrote: > > On Sun, 12 Jul 2009 17:29:07 +0200 (CEST) > "Benny Pedersen" wrote: > >> >> On Sun, July 12, 2009 16:21, RW wrote: >> > Generally forwarders should go into your internal networks, >> >> no no, internal networks is your own wan ips nothing more, imho >> >> forwarders is trusted/msa > > If you do it that way SPF, XBL, DUL etc run against a server that's > inside your trusted network and not against the responsible IP address. > > >> > unless they rewrite the return-path >> >> why does this change ? > > Ideally you want SPF to run against the IP address that delivered to > first MX server; and unless that MX server adds usable SPF headers, you > need to put it into the internal network. If the forwarding server > does Sender Rewriting, SA may not be able to get the original smtp > "mail from" address, and you may want to use the trusted network > instead to run SPF against the rewritten address. > > -- View this message in context: http://www.nabble.com/trusted_networks-and-internal_networks-tp24448374p24451803.html Sent from the SpamAssassin - Users mailing list archive at Nabble.com.
Re: trusted_networks and internal_networks
On Sun, 12 Jul 2009 17:29:07 +0200 (CEST) "Benny Pedersen" wrote: > > On Sun, July 12, 2009 16:21, RW wrote: > > Generally forwarders should go into your internal networks, > > no no, internal networks is your own wan ips nothing more, imho > > forwarders is trusted/msa If you do it that way SPF, XBL, DUL etc run against a server that's inside your trusted network and not against the responsible IP address. > > unless they rewrite the return-path > > why does this change ? Ideally you want SPF to run against the IP address that delivered to first MX server; and unless that MX server adds usable SPF headers, you need to put it into the internal network. If the forwarding server does Sender Rewriting, SA may not be able to get the original smtp "mail from" address, and you may want to use the trusted network instead to run SPF against the rewritten address.
Re: trusted_networks and internal_networks
On Sun, July 12, 2009 16:21, RW wrote: > Generally forwarders should go into your internal networks, no no, internal networks is your own wan ips nothing more, imho forwarders is trusted/msa > unless they rewrite the return-path why does this change ? > or there is a possibility of mail submission, msa networks > in which case thing get a bit more complicated. indeed :) > If you want to add other addresses to trusted remember that they must be > an unbroken chain. best is always to check a giving msg a test like spamassassin 2>&1 -D -t msg | grep untrusted | less to see the untrusted ips and then whois the ips to find the good ips that is not dynamic/untrusted -- xpoint
Re: trusted_networks and internal_networks
On Sun, 12 Jul 2009 05:54:35 -0700 (PDT) MrGibbage wrote: > > I have read the help pages for those two settings over and over, and > I guess I'm just not smart enough. I can't figure out what I should > put for those two settings. Can one of you give me a hand by looking > at the headers from an email? I can tell you that my SA installation > is on "ps11651.dreamhostps.com" and the way I receive email is I my > email is sent to my public email address, "s...@pelorus.org" and I > have an auto-forwarder which sends the mail to my SA box via email, at > skip-mor...@psoneonesixfiveone.dreamhostps.com (mangled here). I > never receive mail directly to > skip-mor...@psoneonesixfiveone.dreamhostps.com. If I did, it would > have to be spam because they scraped the address from somewhere. > pelorus.org and ps11651.dreamhostps.com are the same box. All the > appriver stuff below is done on the sending side of my company's > exchange server. > > Anyway, maybe I got it, but these two settings seemed too important > to get wrong, so I just want to be sure. > > #ps11651.dreamhostps.com and pelorus.org > internal_networks 75.119.219.171 > trusted_networks 75.119.219.171 #I think this is wrong You don't need this address, the server adds the final received header, so the address never appears in the headers. Generally forwarders should go into your internal networks, unless they rewrite the return-path or there is a possibility of mail submission, in which case thing get a bit more complicated. If you want to add other addresses to trusted remember that they must be an unbroken chain.
