Open Relay testing based on recipient domain? Disable?

Mark Martinec Mark.Martinec+amavis at
Wed Aug 3 17:59:26 CEST 2011


> > Apparently you don't have it set, otherwise you would not get the
> > 'Nonlocal recips but not originating' warning.
> Hmm, then can you tell me what is wrong with this?
> postfix/
> content_filter = amavis:[]:10024
> postfix/
> amavis    unix  -       -       n       -       10      smtp
>         -o smtp_send_xforward_command=yes
>         -o disable_dns_lookups=yes
> amavis.conf
> @mynetworks = qw( [::1] [FE80::]/10 [FEC0::]/10
>          );
> $policy_bank{'MYNETS'} = {
>   originating => 1,
>   os_fingerprint_method => undef,
> };

Looks ok, provided that the @mynetworks list really contains
all your networks from which your own clients submit mail.
The above list only contains private IP address pools.

> Is amavis checking against who is handing off the mail (local postfix) or
> the real sending MTA?  It would make sense to do the latter,

The latter, the real sending SNMP client.
The information is passed from Postfix to amavis via an XFORWARD
SMTP extension command, which I see you do have enabled.

> but in that
> case, how is it that the originating flag can override this at all?

Not sure I understand. The activation of a policy bank MYNETS
turns on the originating flag, not the other way around.
And the MYNETS policy bank is loaded when a client's IP address
matches @mynetworks.

> > Depends on whether you care or not, but this will disable bounce killer,
> > penpals scoring, will be adding X-Spam-* AND Authentication-Results
> > to outbound mail too, and affect logging and statistics (SNMP) counters.
> With the exception of adding headers (I add x-virus-scanned to outgoing
> anyway - will this add something else?)

If a recipient is local this enables adding of X-Spam-* header fields
(if you have spam scanning enabled), and adding of Authentication-Results
if you have DKIM verification enabled. The idea is that one would not
want to have his own outgoing mail labeled as spam, not even accidentally.

If you are only doing virus scanning, then this does not affect you.

> I don't know what half these things are.  Where can I read about them?

New features are described in RELEASE_NOTES when they are introduced.
Search release notes for: 'new feature: "pen pals soft-whitelisting"',
'bounce killer feature', and 'Authentication-Results'.

> As I only use amavis to pass
> messages through a virus scanner, I probably don't use these things(??).

Yes, most likely. Pen pals and bounce killer require SQL logging
to be enabled, which you don't have. And you are not letting
amavisd add disclaimers or dafang suspect mail, so this is not
affected either.

The logging (in 2.7.0) would still look funny, claiming an outbound
message is {RelayedInternal} instead of {RelayedOutbound}, and
amavisd-agent (or SNMP) would update wrong statistics counters,
but that is more or less cosmetic.

> > You have the list of your domains already maintained somewhere
> > for the sake of an MTA. You may be able to access the same data,
> > perhaps through SQL or LDAP or an occasional fetch/update script.
> Yes....  is there documentation somewhere on how to make
> @local_domains_maps a lookup instead of an array?

Each @*_maps setting is a list of lookups. A lookup can be
a hashref (associative array), a plain arrayref, a regexp lookup
(a ref to a list of regexp/value pairs), a SQL or LDAP query,
or just a plain constant. These are described in README.lookups.

If you have (or can produce by some simple script) a list of
local domain in a file somewhere, one domain per line, you can
let amavisd read it from a file, construch a hash out of it,
which can be used in a @*_maps. Note: prepend a dot before each
domain name if you need its subdomains to be covered too.

For example:

  @local_domains_maps = ( read_hash("$MYHOME/etc/local_domains") );

which is equivalent to:

  my $href = read_hash("$MYHOME/etc/local_domains");
  @local_domains_maps = ( $href );

The read_hash docs:

# 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" 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.

The file is only read at a startup (or reload) time, it is not dynamic.
If the set of your local domains is not changing too often, then
this should suffice. If the set is being updated often it may
become impractical to 'amavisd reload' it every time, in which
case one may consider using a SQL lookup in @local_domains_maps,
which is dynamic, i.e. sees changes immediately. This involves
a table 'user' (README.sql*) or changing the default SQL
query clause $sql_clause{sel_policy}. The 'local' field is
somewhat special (sensible defaults, need not exist), see
README.lookups in it SQL section. If you have a particular
SQL schema already in place, ask here for advice.


More information about the amavis-users mailing list