amavisd-new, read_hash and problem with a dot in localpart of emailaddress

[Kuehler Guido]

Amavisd-New Version: 1:2.6.5-0ubuntu3.2

 

We must blacklist and whitelist sender-email-adresses and not complete domains, additional we must use different blacklists

and whitelists based on our different recipient-domains.

 

So we have read the Documentation and have our amavis.conf extended with the $per_recip_blacklist_lookup_tables section.

 

$per_recip_blacklist_sender_lookup_tables = {
'.it-power.biz' => read_hash('/etc/amavis/conf.d/blacklist_itp')
};

 

All is ok when we in the external file define email-adresses how na...@domain.com or .domain.com

but when we define an email-address with firstname...@domain.com (in the Example

guido....@steinel.at) we receive the followed error.

 

Stopping amavisd: amavisd-new.
Starting amavisd: Array found where operator expected at /etc/amavis/conf.d/blacklist_itp line 2, at end of line
Error in config file "/etc/amavis/conf.d/blacklist_itp": syntax error at /etc/amavis/conf.d/blacklist_itp line 2, near "kuehler@steinel"
(failed).

So we change our entry in the external File to enclose the complete Email-Address with a  ' sign or a " sign.

 

Example:

 

'guido....@steinel.at' => 1,

 

Result:

 

We can now start amavis without any error and see a successfull match from Amavis for the recipient-domain but amavis have

now no match for the defined sender-emailaddress when the sender-address is also 100% identical in an ckecked email.

 

The Problem exist only when a dot exist in the localpart of the emailaddress and when entryies with read_hash reads from an

external file.

 

I hope any one can give us an tip to resolve this Problem, we have looked very very long around in different

How-Tos, Documentations and have tested amyn variants but with no successfull solution.

 

 

 

Best Regards

Guido Kuehler

 

[Kuehler Guido via amavis-users]

[Mark Martinec via amavis-users]

Guido,

> $per_recip_blacklist_sender_lookup_tables = {
> '.it-power.biz' => read_hash('/etc/amavis/conf.d/blacklist_itp')
> };

> All is ok when we in the external file define email-adresses how

> na...@domain.com <mailto:na...@domain.com> or .domain.com

> but when we define an email-address with firstname...@domain.com

> <mailto:firstname...@domain.com> (in the Example
> guido....@steinel.at <mailto:guido....@steinel.at>) we receive
> the followed error.

> Starting amavisd: Array found where operator expected at
> /etc/amavis/conf.d/blacklist_itp line 2, at end of line
> Error in config file "/etc/amavis/conf.d/blacklist_itp": syntax error at
> /etc/amavis/conf.d/blacklist_itp line 2, near "kuehler@steinel"

Don't place files (such as /etc/amavis/conf.d/blacklist_itp )
into a directory /etc/amavis/conf.d/, which is dedicated to
configurations files in Debian and Ubuntu packaging of amavis.
Files in this directory are interpreted as Perl scripts,
i.e. are amavis config files, like amavisd.conf.

The diagnostics you are seeing comes from Perl itself,
which tries to interpret our file as a Perl program.

Mark

[Mark Martinec via amavis-users]

Guido,

... moreover:

> So we change our entry in the external File to enclose the complete
> Email-Address with a ' sign or a " sign.
> Example:
> 'guido....@steinel.at' => 1,

That's not the right syntax for a file to be read
by read_hash(). The following describes the syntax
as understood by read_hash, no quotes and no '=>' :


# read an associative array (=Perl hash) (as used in lookups) from
# a file; may be called from amavisd.conf
#
# Format: one key per line, anything from '#' to the end of line
# is considered a comment, but '#' within correctly quoted RFC 5321
# addresses is not treated as a comment introducer (e.g. a hash sign
# within "strange # \"foo\" address"@example.com is part of the string).
# Lines may contain a pair: key value, separated by whitespace,
# or key only, in which case a value 1 is implied. Trailing whitespace
# is discarded (iff $trim_trailing_space_in_lookup_result_fields),
# empty lines (containing only whitespace or comment) are ignored.
# Addresses (lefthand-side) are converted from RFC 5321 -quoted form
# into internal (raw) form and inserted as keys into a given hash.
# NOTE: the format is partly compatible with Postfix maps (not aliases):
# no continuation lines are honoured, Postfix maps do not allow
# RFC 5321 -quoted addresses containing whitespace, Postfix only
# allows comments starting at the beginning of a line.

Mark