Open Relay testing based on recipient domain? Disable?

email builder emailbuilder88 at
Wed Aug 3 22:05:58 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.

I understand now.  I thought the MYNETS policy bank was used based on the location of whoever handed off the email for processing (my local Postfix instance).  I was wrong and I understand now.  Now that that's cleared up I can re-state my question...

First, I am seeing this "Open Relay?" message in my logs for *incoming* mail, not mail sent by local or roaming users of my system.  Those messages are most certainly NOT originating on my system, and some of them are delivered to virtual domains not listed in @local_domains_maps.  Is the only solution to ignore the log messages or add a lookup to @local_domains_maps?

Second, I do have roaming users who send (SASL-authenticated) via connections all over the world using Thunderbird/Outlook and the like.  You state that my MTA needs to somehow tell amavis, for example, that mail coming in from port 465 is "originating"?  I guess I'd do that by something like this (changing the amavis port number used by these to 10028)???

$interface_policy{'10028} = 'SASL_AUTHENTICATED';
$policy_bank{'SASL_AUTHENTICATED'} = {
  originating => 1,

This seems like a lot of extra setup for this little annoying log message.  My MTA being correctly set up, I'd prefer not to have to bend over backward to convince amavis that this is the case.  I assume I wouldn't have to add this policy bank if @local_domains_maps used a lookup to gather my virtual domains.

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


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

I do have my domains in a relational database.  The table isn't called "user", but I do have a table of account data.  I do also have another table that just has domain data (domain name as primary key), which would be the better, faster SQL lookup for this purpose.  I imagine some amount of configuration gymnastics would make such a lookup possible?  

An additional issue, as I see it, though, is that this is dynamic in nature?  I'd really prefer that amavis didn't hit my database every time a message is being delivered, and I'm concerned that if there are a lot of amavis threads, each one would be using its own connection and taxing the database unnecessarily.  Does amavis have anything to mitigate these issues?

More information about the amavis-users mailing list