Sorry, I know the topic has been hashed and rehashed several times
recently. I though I understood issues around internal/trusted
networks and I believe that it worked as expected the last time
I checked, but now I'm suprised again, please help me understand it.
This is SA 3.1.3.
We have a MSA which is a separate host from the main MTA, SA runs
on MTA. MSA receives all mail from our users, both from internal
hosts and from authenticated external roaming users, then forwards
all mail to MTA for checking and delivery/forwarding.
The MTA is receiving all mail from outside, plus all mail
submitted by our users through MSA.
As required per docs, the MTA is considered trusted and internal,
and MSA is declared trusted and NOT internal.
(both MSA and MTA are on the same IP network)
A mail from an authorized external user follows the route:
<REMOTE> -> <MSA> -> <MTA+SA>
(I obfuscated IP addresses and host names in the log below
and replaced them with <REMOTE>, <MSA> and <MTA+SA>)
Here are the relevant sections of the log, along with my questions.
dbg: generic: SpamAssassin version 3.1.3
dbg: received-header: relay <MTA+SA> trusted? yes internal? yes
dbg: received-header: relay <MSA> trusted? yes internal? no
dbg: received-header: relay <REMOTE> trusted? no internal? no
So far so good, internal/trusted are recognized correctly.
dbg: dns: checking RBL sbl-xbl.spamhaus.org., set sblxbl-lastexternal
dbg: dns: IPs found: full-external: <MSA>, <REMOTE>
untrusted: <REMOTE> originating:
dbg: dns: only inspecting the following IPs: <MSA>
Is it normal that our own MSA ip address is being submitted for RBL tests?
dbg: dns: checking RBL sbl-xbl.spamhaus.org., set sblxbl
dbg: dns: IPs found: full-external: <MSA>, <REMOTE>
untrusted: <REMOTE> originating:
dbg: dns: only inspecting the following IPs: <REMOTE>
Good, <REMOTE> is being tested for RBL.
dbg: spf: checking EnvelopeFrom (helo=<MSA>, ip=<MSA>,
[EMAIL PROTECTED])
dbg: spf: query for [EMAIL PROTECTED]/<MSA>/<MSA>: result: fail,
comment: Please see http://www.openspf.org/why.html?
sender=mark.martinec%40ijs.si&ip=<MSA>&receiver=<MTA>
Hmm, I don't think that our own <MSA> is supposed to be tested for SPF.
It is normal?
And here is an unfortunate consequence:
pts rule name description
---- ---------------------- --------------------------------------------------
1.2 SPF_FAIL SPF: sender does not match SPF record (fail)
[SPF failed: Please see http://www.openspf.org/why.html?
sender=mark.martinec%40ijs.si&ip=<MSA>&receiver=<MTA>]
Mark
