Home / server / Questions / 592908
In Process
Fox
Asked: 2014-05-04 08:00:52 +0800 CST

How to route some email accounts of a domain with transport_maps to another MX if user doesn't exist locally?

  • 772

The MX server in my domain example.com point to my Postfix server. However, I have also configured a Google Apps account responsible for emails of example.com.

I want all emails to go to my Postfix server (this is already done by the MX setting in the DNS zone), but want some users of this domain to be forwarded to the MX aspmx.l.google.com.

I did this with the transport_maps parameter. Here is the file /etc/postfix/transport.

[email protected] smtp:[aspmx.l.google.com]

The problem is, smtpd_reject_unlisted_recipient is set to yes by default, but postfix checks existence of user before applying the transport map. My Postfix server doesn't know the user test for this domain, so it simply rejects the email.

I would like to make transport routing happen before recipient existence check (in my current setting, only Google SMTP is aware of existence of user test). Is that possible?

Note: local_recipient_maps doesn't work for me because I use the virtual transport with dovecot. So the recipient table is virtual_mailbox_maps.

postfix

2 Answers

  1. Why doesn't the routing happen before the recipient existence check? Isn't there is way? When I route emails, I mean "The current Postfix doesn't handle anything and just forwards email to another server which is fully responsible for the config".

    No, that isn't way postfix gonna works. Recipient existence checks and email routing was two different activities for postfix. Recipient existence checks was performed when accepting email. The process who performs it was smtpd. Email routing was performed when delivering email. The process who perform it was trivial-rewrite

    In the comment, you mention that you use virtual delivery agent from postfix to delivering email. I'm gonna tell you that it possible to achieve no-redundant-information in postfix configuration. BUT you must change current postfix setup.

    To achieve your goal, we must move all domains in virtual_mailbox_domain class to relay_domains class. Then using dovecot LDA to deliver email in the right mailbox. Relay domains class has special parameter called relay_recipient_maps to checks the recipient existence.

    The good news is you can use relay_recipient_maps together with transport_maps. Why? Because relay_recipient_maps only used to check existence of user. The value/right hand side string in transport_maps was ignored when recipient existence check. Snippet from man postconf.

    Optional lookup tables with all valid addresses in the domains that match $relay_domains. Specify @domain as a wild-card for domains that have no valid recipient list, and become a source of backscatter mail: Postfix accepts spam for non-existent recipients and then floods innocent people with undeliverable mail. Technically, tables listed with $relay_recipient_maps are used as lists: Postfix needs to know only if a lookup string is found or not, but it does not use the result from table lookup.

    For the completeness, here the postfix configuration for this setup. Credits to sebokopter for the idea.

    #main.cf
# rename virtual_mailbox_domains to relay_domains
relay_domains = mydomain.example.com
# put the parameter value of virtual_mailbox_maps AND transport_maps parameter
relay_recipient_maps = hash:/my/virtual_mailbox_maps, hash:/my/transport_maps

transport_maps = hash:/my/transport_maps
relay_transport = dovecot:

#master.cf
dovecot   unix  -       n       n       -       -       pipe
    flags=DRhu user=vmail:vmail argv=/usr/local/libexec/dovecot/dovecot-lda -f ${sender} -d ${recipient}
    • 1

  2. Having the same issue, to fix I just created the virtual users in my database and it allowed postfix to complete the recipient existence check and get to rerouting to a different MX Server.

    I know its a bit of a hack, personally it works for me as the accounts that are being rerouted will eventually be relocated to the same MX and so the user accounts are valid.

    • 0