Open Relay testing based on recipient domain? Disable?

[Mark Martinec]

emailbuilder88,

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

Right. So that is the issue with such messages.

> Is the only solution to ignore the log messages or add a lookup to
> @local_domains_maps?

Yes.
(or just comment out the line which issues the warning, if turning
a blind eye on the issue would make you happier)

> 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,
> };

Exactly.

> This seems like a lot of extra setup for this little annoying log message.

Well, this provides a reliable/trustworthy information, passed from
an MTA to amavisd. There is no mechanism in an SMTP protocol that
could pass on such information. Parsing a mail header section is
unreliable and would require amavisd to know a topology of your
mail routing (such as a dedicated MSA host), so it would just shift
the problem, not avoid it. Using a dedicated TCP port seems like
a simple and reliable way to pass on this single bit of information.

This approach works with any mail routing topology, just keep
a mail submission path separate from a MX (inbound) path.

Having a dedicated MSA (mail submission) service is probably a
good idea anyway. It need not be a separate host, can just be
a dedicated IP address/port which allows submission only from
internal networks or authenticated roaming users. All it takes
then is to have a
  -o content_filter=amavisfeed:[127.0.0.1]:10028
on such smtpd service.

Having the same port + IP address for both MX and MSA
complicates things. It is doable, but a bit ugly.
See:
  http://www.ijs.si/software/amavisd/amavisd-new-docs.html#pbanks-ex
(example 3)

> I assume I wouldn't have to add this policy bank if @local_domains_maps
> used a lookup to gather my virtual domains.
> My MTA being correctly set up, I'd prefer not to have to bend over
> backward to convince amavis that this is the case.

These are two completely independent bits of information.

One is the originating flag, which says the message is coming FROM
inside (or form an authenticated user). This is a property of a message
as a whole.

The other is a @local_domains_maps match on a recipient address.
It tells where a message is going TO. This is a property of a recipient.
As a message can have multiple recipients, a message can be
both internal-to-internal and outgoing at the same time.

Both bits are needed for amavisd to know in what direction a
message is passing. Some decisions depend only on 'originating'
flag, some only on a 'recipient is local' bit, and some decisions
are based on both bits of information.

If none of the features depending on this information is used
(or are noncritical, such as statistics) then one can get by
with just ignoring it all.

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

PostgreSQL example:


CREATE TABLE mydomains (domain_name bytea PRIMARY KEY);

INSERT INTO mydomains (domain_name) VALUES
  ('localhost'), ('example.com'), ('example.si');


amavisd.conf:

@local_domains_maps = ();  # no statical lookups, SQL is implicit
$sql_lookups_no_at_means_domain = 1;
$sql_select_policy =
  "SELECT 1 AS id FROM mydomains WHERE ('.' || domain_name) IN (%k)";

If you don't care for subdomains, the following is just as good:

  "SELECT 1 AS id FROM mydomains WHERE domain_name IN (%k)";

or starting with 2.7.0:

  "SELECT 1 AS id FROM mydomains WHERE domain_name = %d";


See 2.7.0 release notes searching for:
  augmented by four new placeholders: %l, %u, %e, and %d
for the explanation of these template placeholders. 


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

Then make a simple shell or a perl script extracting domain names
from SQL writing them to a file, and let amavisd read it into a hash lookup
on reload. It is doable in a dozen or so lines directly in amavisd.conf too.
Currently there is no aggregation/proxying for SQL available.

  Mark