rocsca,
> @bypass_virus_checks_maps = (
> { '.mydomain1.org' => 0, # inbound or internal-to-internal
> '.mydomain2.org' => 0,
> '.' => 1, # skip the check for everybody else (outbound)
> } );
> I have understood quite well your explanation. I have a problem using a
> such approach. Infact, I have a long list of "mydomain" too. I maintain
> domains through a database. But unfortunatly I can't figure out how to
> build a such associative array.
A better approach would probably be to use SQL lookup instead of a
statical hash-based lookup. The policy.bypass_virus_checks SQL field
is equivanent to @bypass_virus_checks_maps (actually it's the other
way around, the SQL lookup table is implicitly prepended to a
lists of lookup tables in @*_maps).
I expect your existing database schema is not the same as
that proposed by amavisd docs (tables users and policy).
Nevertheless, with some SQL magic and existing schema could
be presented to amavisd the way it expects it. The idea is
to present a bypass_virus_checks='N' for all local domains,
and provide a default of a yes for the rest (either by an
SQL record or by a statical default).
When amavisd does an SQL lookup, it executes the SELECT clause
as specified in $sql_clause{'sel_policy'}, which is configurable
in amavisd.conf. The default is:
# The SQL select clause to fetch per-recipient policy settings.
# The %k will be replaced by a comma-separated list of query addresses
# for a recipient (e.g. full address, domain only, catchall), %a will be
# replaced by an exact recipient address (same as the first entry in %k,
# suitable for pattern matching). Use ORDER, if there is a chance that
# multiple records will match - the first match wins (i.e. the first
# returned record). If field names are not unique (e.g. 'id'), the later
# field overwrites the earlier in a hash returned by lookup, which is
# why we use 'users.*, policy.*, users.id'.
SELECT users.*, policy.*, users.id
FROM users LEFT JOIN policy ON users.policy_id=policy.id
WHERE users.email IN (%k) ORDER BY users.priority DESC
The resulting record (only the first matters) only needs to
provide fields with names as in the docs (names are currently
hard-coded, not configurable). Not all fields need to be present,
in fact none are required - just provide the ones that you want
to specify in SQL, others will fall back to statical lookups.
Also table names do not matter. There is also a useful default
for the 'local' field (as documented in README.lookups):
when field name is missing, a mere presence of a resulting
record implies local='Y' unless it is a wildcard '@.' record,
providing a convenient way to specify @local_domains_maps in SQL.
Setting the $sql_clause{'sel_policy'} to a suitable clause,
aided with some SQL magic like subselects, union, aliases, views)
can mould existing schema into what is desired. Some examples
were discussed in the past on the ML - I keep some just
as an illustration, without explaining it now:
# $sql_select_policy =
# 'SELECT 1 FROM domain WHERE CONCAT("@",domain_name) IN (%k)';
#
# $sql_select_policy =
# 'SELECT *, extuser.id'.
# ' FROM ((SELECT id,policy_id,priority,email FROM users) UNION'.
# ' (SELECT 1,99,1,CONCAT("@",domain_name) FROM domain)) AS extuser'.
# ' LEFT JOIN policy ON policy_id=policy.id'.
# ' WHERE email IN (%k) ORDER BY priority DESC';
#
# $sql_select_policy =
# 'SELECT *, user.id'.
# ' FROM (SELECT 1 as id, 99 as policy_id, 1 as priority,'.
# ' CONCAT("@",domain_name) as email FROM domain) AS user'.
# ' LEFT JOIN policy ON policy_id=policy.id'.
# ' WHERE email IN (%k) ORDER BY priority DESC';
#
# $sql_lookups_no_at_means_domain = 1;
# $sql_select_policy =
# 'SELECT *, user.id'.
# ' FROM (SELECT 1 as id, 99 as policy_id, "Y" AS local'.
# ' FROM domain WHERE domain_name IN (%k)) AS user'.
# ' LEFT JOIN policy ON policy_id=policy.id';
> PS: Amavisd-new natively tags as LOCAL some log's entries. If an entry is
> tagged as LOCAL it mean that the associated message is either inbound or
> internal-to-internal. Right? But how behaves Amavisd-new when face with a
> message which has either local and non-local recipients?
A presence of a string 'LOCAL' in the default log template (macro %l)
has changed somewhat in the past. Presently it ONLY and directly reflects
the flag $originating, which can either be set explicitly by a policy bank,
or implicitly by matching SMTP client's IP address to @mynetworks_maps.
If $originating is true you get a 'LOCAL', otherwise not.
So, if you maintain the semantics of $originating as intended
(turned on by mail coming from internal networks or authenticated users),
the LOCAL means that mail is coming from inside, and it doesn't
differentiate between outgoing and internal-to-intrenal.
It doesn't have anything to do with a sender's or recipient's domain name
(unlike in some old versions of amavisd).
> Anyway, since I have set Amavisd-new to avoid virus scan for outbound
> messages, I get a lot of:
>
> Jan 22 11:20:27 av9 postfix/smtp[29723]: 2C9B815B8D9:
> to=<[email protected] >, relay=127.0.0.1[127.0.0.1]:10026, delay=13,
> delays=2.4/9.8/1/0, dsn=4.4.2, status=deferred (conversation with
> 127.0.0.1[127.0.0.1] timed out while receiving the initial server
> greeting)
>
> As well
>
> Jan 22 11:20:11 av9 postfix/smtp[29723]: B5D8D15B8BF:
> to=<[email protected]>, relay=127.0.0.1[127.0.0.1]:10024, delay=8.1,
> delays=2.9/4.3/1/0, dsn=4.4.2, status=deferred (conversation with
> 127.0.0.1[127.0.0.1] timed out while receiving the initial server
> greeting)
>
> I can't figure out why.. Maybe postfix answer so when amavisd-new has no
> child to manage a new request?
Yes, this is the most likely reason. Overbooking of child processes.
> And so this is due to the high incoming
> traffic? Or there is some tune to be done in my master.cf?
>
> smtp-amavis unix - - n - 14 smtp
> -o smtp_data_done_timeout=1200
> -o smtp_send_xforward_command=yes
> -o disable_dns_lookups=yes
> -o max_use=14
> -o smtp_connect_timeout=1
> -o smtp_helo_timeout=1
>
> The big problem is that the messages remains starngely queued a long
> time before to be forwarded toward Amavisd-new... :-(
Either keep the sum of all postfix smtp feeder processes (maxproc 14 here)
below (or the same as) the amavisd child process count $max_servers),
OR disable postfix smtp_connection_cache_on_demand on all
feeder processes (like the one above), by adding it an option:
-o smtp_connection_cache_on_demand=no
> Indead I have changed the conf in /etc/postfix/master.cf above with the
> following:
>
> smtp-amavis unix - - n - 2 smtp
> -o smtp_data_done_timeout=1200
> -o smtp_send_xforward_command=yes
> -o disable_dns_lookups=yes
> -o max_use=30
> -o smtp_connect_timeout=1
> -o smtp_helo_timeout=1
>
> And I do not have any error of kind:
>
> "...delivery temporarily suspended: conversation with
> 127.0.0.1[127.0.0.1] timed out while receiving the initial server
> greeting..."
bacause you reduced maxproc to 2.
Mark
------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
AMaViS-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/amavis-user
AMaViS-FAQ:http://www.amavis.org/amavis-faq.php3
AMaViS-HowTos:http://www.amavis.org/howto/
