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
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:
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
|
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_networks
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
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_networks
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
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
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
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
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
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
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
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
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
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
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
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
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.
An SPF_PASS is pretty worthless
But awfully handy for whitelist_from_spf.
--
Dave Pooser
Cat-Herder-in-Chief, Pooserville.com
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
|
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
|
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
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
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:
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_networks
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
|
27 matches
Mail list logo
