Re: Howto stop SPF_FAIL from internal network?
On Thu, March 27, 2008 11:28, Enrico Scholz wrote: Benny Pedersen [EMAIL PROTECTED] writes: spamassassin 21 -D spf -t /tmp/msg /tmp/msg.spf.debug post the debug file https://www.cvg.de/people/ensc/spf_fail.txt info: generic: trusted_networks doesn't contain msa_networks entry '192.168.0.0/16' this is fail and disable plugins that are not installed anyway in the pre files this line here i dont like dbg: metadata: X-Spam-Relays-External: [ ip=192.168.3.24 rdns=ensc-virt.intern.sigma-chemnitz.de helo=ensc-virt.intern.sigma-chemnitz.de by=mail.cvg.de ident= envfrom= intl=0 id=m2RA9lJc010009 auth= msa=0 ] that ip can't be external :/ is the problem that you have non route ip in the wan ip nic as alias ? show me netstat -nr or ip addr show and ip route show (full debug with configuration of | $ sed '/^\(#.*\)\?$/d' ~/.spamassassin/user_prefs | internal_networks 62.153.82.30 | trusted_networks62.153.82.30 | trusted_networks192.168.8.0/23 ups ? (to wide) | trusted_networks!192.168.3.0/24 | msa_networks192.168.0.0/16 result is SPF_NEUTRAL now as I added 192.168.0.0 net to SPF entry) non route ip range makes no sense in spf Benny Pedersen Need more webspace ? http://www.servage.net/?coupon=cust37098
Re: Howto stop SPF_FAIL from internal network?
Benny Pedersen [EMAIL PROTECTED] writes: https://www.cvg.de/people/ensc/spf_fail.txt info: generic: trusted_networks doesn't contain msa_networks entry '192.168.0.0/16' this is fail You mean, that this is a bug in Spamassassin? this line here i dont like dbg: metadata: X-Spam-Relays-External: [ ip=192.168.3.24 rdns=ensc-virt.intern.sigma-chemnitz.de helo=ensc-virt.intern.sigma-chemnitz.de by=mail.cvg.de ident= envfrom= intl=0 id=m2RA9lJc010009 auth= msa=0 ] that ip can't be external :/ That's the internal/private host which sends the mail and generates the SPF_FAIL. There is no reason/way to make it external. result is SPF_NEUTRAL now as I added 192.168.0.0 net to SPF entry) non route ip range makes no sense in spf ... but seems to be the easiest way to prevent the false SPF_FAIL... Enrico
Re: Howto stop SPF_FAIL from internal network?
Benny Pedersen [EMAIL PROTECTED] writes: spamassassin 21 -D spf -t /tmp/msg /tmp/msg.spf.debug post the debug file https://www.cvg.de/people/ensc/spf_fail.txt (full debug with configuration of | $ sed '/^\(#.*\)\?$/d' ~/.spamassassin/user_prefs | internal_networks 62.153.82.30 | trusted_networks62.153.82.30 | trusted_networks192.168.8.0/23 | trusted_networks!192.168.3.0/24 | msa_networks192.168.0.0/16 result is SPF_NEUTRAL now as I added 192.168.0.0 net to SPF entry) Enrico
Re: Howto stop SPF_FAIL from internal network?
Benny Pedersen [EMAIL PROTECTED] writes: I have a problem that mails from internal (private) IPs generate SPF_FAIL hits. E.g. my configuration is | internal_networks 62.153.82.30 | internal_networks 192.168.0.0/16 | trusted_networks62.153.82.30 | trusted_networks192.168.8.0/24 ... trusted_networks !192.168.3.0/24 What would be the difference between the current | trusted_networks62.153.82.30 | trusted_networks192.168.8.0/24 ? SPF_FAIL for private network happens in both cases. perldoc Mail::SpamAssassin::Plugin::SPF see how to use authed headers for authed users 1. I do not need SMTP auth (and SPF is it not worth to change this) 2. mentioned manpage of spamassassin 3.2.4 does not contain the string 'auth' perldoc Mail::SpamAssassin::Conf see msa_ defines SPF_FAIL still happens with | msa_networks192.168.0.0/16 Enrico
Re: Howto stop SPF_FAIL from internal network?
On Wed, March 26, 2008 09:24, Enrico Scholz wrote: | msa_networks192.168.0.0/16 spamassassin 21 -D spf -t /tmp/msg /tmp/msg.spf.debug post the debug file /tmp/msg is a email where it happends Benny Pedersen Need more webspace ? http://www.servage.net/?coupon=cust37098
Re: Howto stop SPF_FAIL from internal network?
Benny Pedersen [EMAIL PROTECTED] writes: I have a problem that mails from internal (private) IPs generate SPF_FAIL hits. E.g. my configuration is | internal_networks 62.153.82.30 | internal_networks 192.168.0.0/16 | | trusted_networks62.153.82.30 | trusted_networks192.168.8.0/24 192.168.3.0/24 ... is not trusted Enrico
Re: Howto stop SPF_FAIL from internal network?
Benny Pedersen [EMAIL PROTECTED] writes: internal and trusted should be all ips you have access to but not open to the whole world Documentation about trusted_networks says something else: A trusted host could conceivably relay spam, but will not originate it, and will not forge header data. Clients in 192.168.3.0/24 net are ordinary user machines potentially infected by spam bots (-- originating spam and forging header data) and must not be in 'trusted_networks' hence. Enrico
Re: Howto stop SPF_FAIL from internal network?
Benny Pedersen [EMAIL PROTECTED] writes: internal and trusted should be all ips you have access to but not open to the whole world On 25.03.08 10:46, Enrico Scholz wrote: Documentation about trusted_networks says something else: A trusted host could conceivably relay spam, but will not originate it, and will not forge header data. Clients in 192.168.3.0/24 net are ordinary user machines potentially infected by spam bots (-- originating spam and forging header data) and must not be in 'trusted_networks' hence. neither in internal_networks as I already pointed out ;) only your mail infrastructure (e.g. MX backups, SMTP filters etc) should be in internal_networks. fix this and then see what SPF checks will produce -- Matus UHLAR - fantomas, [EMAIL PROTECTED] ; 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. Despite the cost of living, have you noticed how popular it remains?
Re: Howto stop SPF_FAIL from internal network?
Matus UHLAR - fantomas [EMAIL PROTECTED] writes: only your mail infrastructure (e.g. MX backups, SMTP filters etc) should be in internal_networks. fix this and then see what SPF checks will produce citing from [EMAIL PROTECTED]: ok; fixed it by removing the 192.168.0.0/16 from 'internal_networks'. But problem still persists that senders from the private 192.168.0.0/16 network are tagged with SPF_FAIL. Enrico
RE: Howto stop SPF_FAIL from internal network?
ok; fixed it by removing the 192.168.0.0/16 from 'internal_networks'. But problem still persists that senders from the private 192.168.0.0/16 network are tagged with SPF_FAIL. Enrico Having watched the thread and not fully recalling every post... I have not checked this, yet has anyone looked in the SPF code areas to see if private network space is handled differently? Again, I have not. Otherwise, do some private dns, some special MTA handling, or whatever and be done with it. Just don't let the private network dns leak to the public nets. There are several dozen reasonable solutions to this, isn't there? - rh
Re: Howto stop SPF_FAIL from internal network?
On 25.03.08 16:11, Enrico Scholz wrote: Matus UHLAR - fantomas [EMAIL PROTECTED] writes: only your mail infrastructure (e.g. MX backups, SMTP filters etc) should be in internal_networks. fix this and then see what SPF checks will produce citing from [EMAIL PROTECTED]: ok; fixed it by removing the 192.168.0.0/16 from 'internal_networks'. But problem still persists that senders from the private 192.168.0.0/16 network are tagged with SPF_FAIL. aha, so you should check now, why do those fail. Is that your domain SPF checks fail for? If so, your users should probably use SMTP authentication when sending e-mail. -- Matus UHLAR - fantomas, [EMAIL PROTECTED] ; 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. Spam is for losers who can't get business any other way.
RE: Howto stop SPF_FAIL from internal network?
aha, so you should check now, why do those fail. Is that your domain SPF checks fail for? If so, your users should probably use SMTP authentication when sending e-mail. -- Matus UHLAR Matus You are bright, and as you know, that will not fix SPF issue if they are still SA scanning the emails after the auth / accept. - rh
Re: Howto stop SPF_FAIL from internal network?
Matus UHLAR - fantomas [EMAIL PROTECTED] writes: But problem still persists that senders from the private 192.168.0.0/16 network are tagged with SPF_FAIL. aha, so you should check now, why do those fail. Perhaps, because spamassassin does not provide an option to disable SPF scan for certain sender ips? Known and mentioned workarounds (private DNS views, SMTP auth) are too heavy weighted for my setup. Is that your domain SPF checks fail for? What would be the sideeffects of adding '+ip4:192.168.0.0/16' to the SPF record? Enrico
Re: Howto stop SPF_FAIL from internal network?
Matus UHLAR - fantomas [EMAIL PROTECTED] writes: But problem still persists that senders from the private 192.168.0.0/16 network are tagged with SPF_FAIL. aha, so you should check now, why do those fail. On 25.03.08 17:47, Enrico Scholz wrote: Perhaps, because spamassassin does not provide an option to disable SPF scan for certain sender ips? Maybe the SA people decided not to do that. Maybe only those should provide SPF records who can verify their own customers - why should you use SPF otherwise? Is that your domain SPF checks fail for? What would be the sideeffects of adding '+ip4:192.168.0.0/16' to the SPF record? mailservers on other networks could have FP's when receiving spam with your domain from their private networks... -- Matus UHLAR - fantomas, [EMAIL PROTECTED] ; 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. There's a long-standing bug relating to the x86 architecture that allows you to install Windows. -- Matthew D. Fuller
Re: Howto stop SPF_FAIL from internal network?
On Tue, 2008-03-25 at 17:47 +0100, Enrico Scholz wrote: Matus UHLAR - fantomas [EMAIL PROTECTED] writes: What would be the sideeffects of adding '+ip4:192.168.0.0/16' to the SPF record? For one thing, you would describe your internal topology to every hacker in the world Secondly, you would allow anyone to forge your mail everyone else's internal networks in the 192.168/16 address space. Isn't the fix just to add 192.168.0.0/16 to trusted_networks? -- Daniel J McDonald, CCIE #2495, CISSP #78281, CNX Austin Energy http://www.austinenergy.com signature.asc Description: This is a digitally signed message part
Re: Howto stop SPF_FAIL from internal network?
Matus UHLAR - fantomas [EMAIL PROTECTED] writes: Maybe the SA people decided not to do that. Maybe only those should provide SPF records who can verify their own customers - why should you use SPF otherwise? Sorry, I don't understand the logic behind this... What would be the sideeffects of adding '+ip4:192.168.0.0/16' to the SPF record? mailservers on other networks could have FP's when receiving spam with your domain from their private networks... An SPF_PASS is pretty worthless (there are rumors that more SPF_PASS are generated by spammers than by legitimate mail ;) ), but SPF_FAIL can give important scores to mark spam as such one. For now, I added the whole IANA blackhole ranges to my SPF record... The openspf documentation uses this in an example too so it should be ok. Enrico
Re: Howto stop SPF_FAIL from internal network?
Matus UHLAR - fantomas [EMAIL PROTECTED] writes: Maybe the SA people decided not to do that. Maybe only those should provide SPF records who can verify their own customers - why should you use SPF otherwise? On 25.03.08 18:25, Enrico Scholz wrote: Sorry, I don't understand the logic behind this... I mean, is SPF usefull for a domain, when some hosts (even not trusted) can send you mail from that domain, without authentication? What would be the sideeffects of adding '+ip4:192.168.0.0/16' to the SPF record? mailservers on other networks could have FP's when receiving spam with your domain from their private networks... An SPF_PASS is pretty worthless (there are rumors that more SPF_PASS are generated by spammers than by legitimate mail ;) ), but SPF_FAIL can give important scores to mark spam as such one. I should have said FN's. Hosts would get SPF_PASS even when they should get SPF_FAIL. So, any server in the world using internal addresses in 192.168/16 could be spammed by hosts on the same network, using your domain and the spams would get SPF_PASS. And you would get bounces. For now, I added the whole IANA blackhole ranges to my SPF record... The openspf documentation uses this in an example too so it should be ok. So anyone with private range can now spam using your domain on its network, without SPF to fire? Why? -- Matus UHLAR - fantomas, [EMAIL PROTECTED] ; 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. BSE = Mad Cow Desease ... BSA = Mad Software Producents Desease
Re: Howto stop SPF_FAIL from internal network?
McDonald, Dan [EMAIL PROTECTED] writes: What would be the sideeffects of adding '+ip4:192.168.0.0/16' to the SPF record? For one thing, you would describe your internal topology to every hacker in the world imo, knownledge that there are IPs from the 10.0.0.0/8 or 192.168.0.0/16 range provides a small gain only Secondly, you would allow anyone to forge your mail everyone else's internal networks in the 192.168/16 address space. Will work only, when mail is delivered within this subnet. When it goes to another MTA, an SPF_FAIL is generated Isn't the fix just to add 192.168.0.0/16 to trusted_networks? no ([EMAIL PROTECTED]) EnricoOB
Re: Howto stop SPF_FAIL from internal network?
Matus UHLAR - fantomas [EMAIL PROTECTED] writes: I mean, is SPF usefull for a domain, when some hosts (even not trusted) can send you mail from that domain, without authentication? Why not? Senders from this domain are allowed from a certain IP only. Everything else should fire SPF_FAIL. But gain of SPF is not large enough to establish infrastructure changes like private DNS views or SMTP auth. For now, I added the whole IANA blackhole ranges to my SPF record... The openspf documentation uses this in an example too so it should be ok. So anyone with private range can now spam using your domain on its network, without SPF to fire? Why? Because it seems to be impossible to configure spamassassin so that it stops SPF_FAIL hits from the internal network? Enrico
Re: Howto stop SPF_FAIL from internal network?
An SPF_PASS is pretty worthless But awfully handy for whitelist_from_spf. -- Dave Pooser Cat-Herder-in-Chief, Pooserville.com
Re: Howto stop SPF_FAIL from internal network?
On Tue, March 25, 2008 10:40, Enrico Scholz wrote: Benny Pedersen [EMAIL PROTECTED] writes: I have a problem that mails from internal (private) IPs generate SPF_FAIL hits. E.g. my configuration is | internal_networks 62.153.82.30 | internal_networks 192.168.0.0/16 | trusted_networks62.153.82.30 | trusted_networks192.168.8.0/24 192.168.3.0/24 ... is not trusted trusted_networks !192.168.3.0/24 perldoc Mail::SpamAssassin::Plugin::SPF see how to use authed headers for authed users perldoc Mail::SpamAssassin::Conf see msa_ defines Benny Pedersen Need more webspace ? http://www.servage.net/?coupon=cust37098
Re: Howto stop SPF_FAIL from internal network?
On Wed, March 19, 2008 18:42, Enrico Scholz wrote: Hi, I have a problem that mails from internal (private) IPs generate SPF_FAIL hits. E.g. my configuration is | internal_networks 62.153.82.30 | internal_networks 192.168.0.0/16 | | trusted_networks62.153.82.30 | trusted_networks192.168.8.0/24 192.168.3.0/24 Then, an (untrusted but internal) host like 192.168.3.24 sends a mail from [EMAIL PROTECTED]. The generated header is or change to 192.168.0.0/16 Benny Pedersen Need more webspace ? http://www.servage.net/?coupon=cust37098
Re: Howto stop SPF_FAIL from internal network?
On Thu, March 20, 2008 16:48, Enrico Scholz wrote: ok; fixed it by removing the 192.168.0.0/16 from 'internal_networks'. But problem still persists that senders from the private 192.168.0.0/16 network are tagged with SPF_FAIL. if you have nic cards that are open to the air with that ip range you should not trust them, but this is very uncommon to have non routeble ip as wan ip :-) if you want strict checking do 192.168.3.0/24 that will still not cover when one sends mails from 192.168.0.0/16 mta headers as internal internal and trusted should be all ips you have access to but not open to the whole world Benny Pedersen Need more webspace ? http://www.servage.net/?coupon=cust37098
Re: Howto stop SPF_FAIL from internal network?
On torsdagen den 20 mars 2008, Matus UHLAR - fantomas wrote: you probably do not understand the internal_networks meaning. internal networks are only those (fully) under your control, trusted may not be under your control but you have to trust them I'd say that internal_networks contain hosts that receive mail from random hosts for you, including secondary MXes. Even hosts handling mailing lists that you subscribe to, and other hosts that you have forward mail to you, may be worth adding, if you can trust them. The reason is that certain DNSBL rules check the address of the last external server that handled the mail, and the server you want to check in the case of list mail is not the list server but the server that delivered the mail to the list server. -- Magnus Holmgren[EMAIL PROTECTED] (No Cc of list mail needed, thanks) Exim is better at being younger, whereas sendmail is better for Scrabble (50 point bonus for clearing your rack) -- Dave Evans signature.asc Description: This is a digitally signed message part.
Re: Howto stop SPF_FAIL from internal network?
On torsdagen den 20 mars 2008, Matus UHLAR - fantomas wrote: you probably do not understand the internal_networks meaning. internal networks are only those (fully) under your control, trusted may not be under your control but you have to trust them On 21.03.08 19:01, Magnus Holmgren wrote: I'd say that internal_networks contain hosts that receive mail from random hosts for you, including secondary MXes. yes, that's the purpose of internal_networks Even hosts handling mailing lists that you subscribe to, and other hosts that you have forward mail to you, may be worth adding, if you can trust them. The reason is that certain DNSBL rules check the address of the last external server that handled the mail, and the server you want to check in the case of list mail is not the list server but the server that delivered the mail to the list server. hosts handling mailing lists should send mail with their own mail from: to SPF records of the senders' domains shouldn't apply -- Matus UHLAR - fantomas, [EMAIL PROTECTED] ; 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. It's now safe to throw off your computer.
Re: Howto stop SPF_FAIL from internal network?
On 19.03.08 18:42, Enrico Scholz wrote: I have a problem that mails from internal (private) IPs generate SPF_FAIL hits. E.g. my configuration is | internal_networks 62.153.82.30 | internal_networks 192.168.0.0/16 | | trusted_networks62.153.82.30 | trusted_networks192.168.8.0/24 I guess this is an error in your setup. The internal_networks should not be browder than trusted_networks. Then, an (untrusted but internal) host like 192.168.3.24 sends a mail from [EMAIL PROTECTED]. The generated header is you probably do not understand the internal_networks meaning. internal networks are only those (fully) under your control, trusted may not be under your control but you have to trust them -- Matus UHLAR - fantomas, [EMAIL PROTECTED] ; 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. Chernobyl was an Windows 95 beta test site.
Re: Howto stop SPF_FAIL from internal network?
Matus UHLAR - fantomas [EMAIL PROTECTED] writes: I have a problem that mails from internal (private) IPs generate SPF_FAIL hits. E.g. my configuration is | internal_networks 62.153.82.30 | internal_networks 192.168.0.0/16 | | trusted_networks62.153.82.30 | trusted_networks192.168.8.0/24 I guess this is an error in your setup. The internal_networks should not be browder than trusted_networks. ok; fixed it by removing the 192.168.0.0/16 from 'internal_networks'. But problem still persists that senders from the private 192.168.0.0/16 network are tagged with SPF_FAIL. Enrico
