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
Then, an (untrusted
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
|
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
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
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:
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
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.
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:
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:
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:
[EMAIL PROTECTED] writes:
So, as I've found in RFC's all header fields in message should
be encoded to 7-bit data.
s/should/must/
In addition my SMTP server does *not* support 8-bit MIME for
incoming e-mail.
That's very uncommon and lot of mail will be probably rejected
due to this.
Matus UHLAR - fantomas [EMAIL PROTECTED] writes:
In addition my SMTP server does *not* support 8-bit MIME for
incoming e-mail.
That's very uncommon and lot of mail will be probably rejected
due to this.
are there known problems with mailers that can send/receive
8-bit but can't encode
14 matches
Mail list logo
