This is related to the topic 'trusted_networks?' from last weak,
but instead of snatching the thread I'll start a new one.
Meanwhile I've read and re-read the Mail::SpamAssassin::Conf
man page, but I'm no wiser. Using SA 3.1, Postfix, amavisd-new.
I have a mail relay on an internal network serving as a submission
mail relay (let's call it MSA, 193.2.4.152) for internal as well as
authenticated external users, e.g. dial-ups via foreign ISP.
This MSA feeds all mail to the main MTA on the same network,
where SA is running, which in turn redistributes it where necessary.
According to SA docs on trusted/internal_networks, the
MSA is to be included in the trusted_networks list, and not in
internal_networks.
(incidently, this is quite a pain to do, instead of something like:
trusted_networks 193.2.4.0/24
internal_networks !193.2.4.152 193.2.4.0/24
one needs to use a contortion like:
trusted_networks 193.2.4.0/24
internal_networks 193.2.4.0/25 193.2.4.128/28 193.2.4.144/29
internal_networks 193.2.4.153 193.2.4.154 193.2.4.155
internal_networks 193.2.4.156/30 193.2.4.160/27 193.2.4.192/26
Btw, other host on the net are to be listed in internal_networks because
some Unix hosts tend to submit their mail indirectly through their private
MTA and not necessarily directly from MUA (depending on their admins),
which means that such hosts should be treated as internal relays.
)
Now the question. A mail submitted to MSA from an external
authenticated client (which also happens to be DUL-listed) uses
a sender address of our domain (as it should be, according to SPF docs).
The SPF check (as done by SA) submits this foreign IP address to SPF,
which naturally claims it is a forgery. This is clearly wrong, the IP address
submitted to SPF should be that of MSA, or SPF check should be
skipped altogether.
To clarify, the following are the only two Received header fields
in that mail:
Received: from MSA by our main MTA
Received: from foreign IP client by MSA
Interestingly, if I remove the MSA IP address from trusted_networks,
the SPF check does use the correct IP address, i.e. that of the MSA.
... but in this case the DUL check strikes in and penalizes the foreign
client IP address.
MSA listed in x_networks:
trusted internal
0 0 SPF ok, no DUL hit
0 1 SPF ok, no DUL hit
1 0 SPF fails, no DUL hit
1 1 SPF fails, DUL hits
So, is SPF when called by SA getting the wrong IP address in case of
authenticated mail from a foreign MUA submitted through our MSA
which is listed in trusted_networks (and not in internal_networks)?
Mark
