Phil,
Hmmm, this is a little confusing then. Postfix is set to forward via
LMTP on tcp/10024 and in amavisd.conf I have:
$interface_policy{'10024'} = 'POLICY-IN';
$policy_bank{'POLICY-IN'} = {
originating => 0,
bounce_killer_score => 1,
penpals_bonus_score => 1,
};
and from the internal network when it sends out it should hit:
$policy_bank{'MYNETS'} = { # mail originating from @mynetworks
originating => 1, # is true in MYNETS by default, but let's make it
explicit
os_fingerprint_method => undef, # don't query p0f for internal
clients
allow_disclaimers => 0,
log_level => 1,
penpals_bonus_score => undef,
bounce_killer_score => 0,
};
as I have specified the correct mynetworks variable. When email comes
in from external it does look okay:
amavis[19518]: (19518-01) Passed CLEAN {RelayedInbound}, POLICY-IN
[216.207.245.17]:33321 [198.245.16.142]
<asterisk-users-boun...@lists.digium.com>
but what is odd is when I send out:
amavis[19517]: (19517-01) Checking: IQESxMhvS-Ec POLICY-IN/MYNETS
[172.30.10.11]
is one policy map overriding the other or is it treating the internal
networks as external as-well ?
As each policy is loaded in turn it overrides current settings
with its own values and can affect subsequent processing/decisions.
So yes, a later-loaded policy overrides previously applied settings.
Policy banks are loaded in the order as the information trickles in,
as follows:
- port/interface -based first (%interface_policy, like your POLICY-IN),
as soon as a connection is made,
- based on client's IP address (@client_ipaddr_policy, MYNETS)
- based on a virus name next (%virus_name_to_policy_bank_maps)
- DKIM based @author_to_policy_bank_maps
- and potentially any policy bank loaded by custom hooks
So in your case loading of MYNETS with its penpals_bonus_score=>undef
overrides previously loaded penpals_bonus_score=>1 by POLICY-IN.
I don't see a good reason to modify $penpals_bonus_score setting
by a policy bank. Just assign a value to a global setting
$penpals_bonus_score and leave out the policy bank overrides
for it.
Should add that I am also using MySQL
storage so is this valid ?
@storage_sql_dsn = @lookup_sql_dsn;
@storage_redis_dsn = (
{ server => '172.30.10.20:6379', db_id => 1 },
);
Yes, it is valid, you can use both the SQL and Redis.
The main purpose of @storage_sql_dsn is to store all information
on both incoming and outgoing mail for whatever needs. In passing
it also serves as a source of data for the penpals feature.
As when I check the Redis database there are no keys :(
172.30.10.20:6379> keys *
(empty list or set)
On the other hand a Redis database is not intended as a
long-term or archival database. As such it only stores minimally
necessary amount of information on internally originating mail,
so that a penpals score can be computed when an incoming message
arrives. For this reason no data is stored to redis if $originating
flag is false (like in your case for every mail).
When both SQL and Redis are used for penpals, the more favourable
value of the two is used. (there can be small differences due to
the number of history records kept in each database, and differences
due to bridging a partition_tag in SQL, if used). This may change
in the future, currently both are used as a safety measure since
times when a Redis support was still being developed.
Mark