Open Relay testing based on recipient domain? Disable?

[email builder]

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

Right.  Thanks for taking the time to write such a thorough explanation.  I guess for me it comes down to only using amavis currently as a virus scanner.  I find Postfix to have enough controls so as to make the rest of amavis' policy controls redundant.  (Or am I missing anything amavis has that Postfix does not?) (I choose to run spam scanning at delivery time so users have more custom control over spam scanning configuration (which may now be possible by amavis(?) but was not many years ago when I set this up.)

> See:
>   http://www.ijs.si/software/amavisd/amavisd-new-docs.html#pbanks-ex
> (example 3)

Nice writeup.  Personally, I think it is more clear and easier to maintain if you specify the content filter port in each separate service definition in master.cf and leave smtpd_sender_restrictions more clean.  It's easy to set up a special smtpd port for local webmail as well as one for submission on 465/587 and use -o content_filter... there which seems easier and more intentional.

But anyhow....  

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

OK, thanks again for making this point clear.  In the end, yes, it seems just setting @local_domains_maps to ( 1 ) seems fine in my case.

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

Woa, that's a cryptic setting name.  :-)  Anyhow, I am going to keep this around for future use, so thank you for explaining this bit.  Much appreciated, as is your great software in general!!!

> $sql_select_policy =
>   "SELECT 1 AS id FROM mydomains WHERE ('.' || domain_name) IN 
> (%k)";

By the way, how does this match correctly?  If %k is something like "test at example.com, example.com, @example.com" (or whatever - maybe it's just not clear what %k is), then ".example.com" does not match.  I know I must be misunderstanding this.....

Thanks again.


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