On Mon, Jan 24, 2011 at 03:52:18PM +0100, Heinz A. Krebs wrote:

> dear all,
> 
> i'm going to setup a backup-MX, and although i've now a working
> solution, I'd like to ask, if this is the correct solution ...
> 
> PART 1 (working):
> Backup for domain.com with a list of valid recipients in a database. my
> main.cf looks like:
> 
> ---------------------------
> relay_domains = domain.com
> relay_recipient_maps = mysql:/etc/postfix/mysql_relay.cf
> # contains query = SELECT 'OK' FROM recipients WHERE email='%s'
> smtpd_recipient_restrictions = 
>   ...,
>   check_recipient_access mysql:/etc/postfix/mysql_relay.cf,

The access check is generally not needed, by listing the
domain in "relay_domains" you ensure that it is not rejected by
"reject_unauth_destination".

> b) if postfix receives mail for t...@domain.com, then postfix answers
> "User unknown in relay recipient table".
> 
> but since my database-list is updated only once per week, i'd like check
> the primary MX in situation b), if in the meantime user TWO has been
> added.

It is best to avoid this mess by synchronizing more frequently, and
pre-provisioning email addresses sufficiently early in the user account
creation process that by the time people are sending the user email,
the data is already on the backup MX.

If that's impractical, DON'T check with the primary, the only time you
need a backup MX is when the primary is down, and that's exactly when
this won't work. So just assume the primary is down, and act accordingly.
This means that you should "defer" all unknown users. Since the primary
will reject them, this only happens when the primary is down, and in this
case you accept and queue just the most recently updated list of recipients.

> 
> ---------------------------
> relay_domains = domain.com
> relay_recipient_maps = mysql:/etc/postfix/mysql_relay.cf
> # contains query = SELECT 'OK' FROM recipients WHERE email='%s'
> smtpd_recipient_restrictions = 
>   ...,
>   check_recipient_access mysql:/etc/postfix/mysql_relay.cf,
>   check_recipient_access hash:/etc/postfix/domains
> # contains: domain.com reject_unverified_recipient

Change "reject_unverified_recipient" to "defer".

> PART 3 (problem):
> domain.at is an alias for domain.com. so i added the following:
> 
> ---------------------------
> virtual_alias_maps = pcre:/etc/postfix/virtual.pcre
> # contains /^([a-z\.]+)@domain.at$/       $1...@domain.com
> ---------------------------

Bad idea. Breaks recipient validation. If this is also to be a relay
domain for which you are a backup you need a table of valid recipients
for this domain. If it is an "alias", you need data that contains
the same localpart addresses with the new domain suffix.

> ---------------------------
> domain.at reject_unverified_recipient
> ---------------------------
> 
> if postfix receives mail for o...@domain.at, then the address is
> rewritten to o...@domain.com, but then the primary MX is immediately
> queried! why is postfix not checking the mysql-database after
> rewriting??????????

Because it checks before.

> MY CURRENT SOLUTION (working):
> extend smtpd_recipient_restrictions in main.cf:
> 
> ---------------------------
> # contains query = SELECT 'OK' FROM recipients WHERE email='%s'
> smtpd_recipient_restrictions = 
>   ...,
>   check_recipient_access mysql:/etc/postfix/mysql_relay.cf,
>   check_recipient_access mysql:/etc/postfix/mysql_relay_at.cf,
> # contains query = SELECT 'OK' FROM recipients WHERE email=REPLACE('%
> s','.at','.com')

NO, don't alias all ".at" domains to ".com", replace just the domain
in question and only at the *end* of the address string.

> this is working, so if postfix receives mail for o...@domain.at it
> answers with OK, since the second table lookup returns a record, and if
> postfix receives t...@domain.at, the mails queryies the primary MX if
> t...@domain.com exists ...
> 
> but is this the correct solution? is there a more easy way to solve
> this?

Better to treat the identical address lists for the two domains as
an "coincidence" that is subject to change and populate data for
both domains.

-- 
        Viktor.

Reply via email to