How to change recipient on Postfix relay (smtp_generic_maps not working)?

Question

I have a Postfix mail gateway setup and would like to change the recipient address. I want all mail being relayed for [email protected] to instead by relayed to [email protected] I have Postfix configured using smtp_generic_maps (as below) however this only works for mail being generated on the Postfix server itself. Any mail being relayed through the Postfix server still goes to [email protected] effectively ignoring smtp_generic_maps. What configuration should I look into to accomplish this?

# grep smtp_generic_maps main.cf
smtp_generic_maps = hash:/etc/postfix/generic

# postmap /etc/postfix/generic
# service postfix reload

# cat /etc/postfix/generic
[email protected]               [email protected]

You shouldn't use smtp_generic_maps for this

The Postfix Address Rewriting Readme describes the correct use for smtp_generic_maps:

With the smtp_generic_maps parameter you can specify generic(5) lookup tables that replace local mail addresses by valid Internet addresses when mail leaves the machine via SMTP. The generic(5) mapping replaces envelope and header addresses, and is non-recursive. It does not happen when you send mail between addresses on the local machine.

You are trying to use it (instead of replacing local addresses like [email protected]) for replacing an address with FQDN [email protected]. As yahoo.com is not configured in mydestination it is not considered as a local domain, thus not processed by generic(5) mapping.

However, you should not configure a domain of someone else as a local domain as it really should be handled by smtp(8) delivery agent instead. Doing so would prevent any user sending mail to any @yahoo.com address. That kind of tampering would be technically incorrect and maybe even illegal.

---

Leading users towards company policy by check_recipient_access

If the problem is that someone is trying to email your CEO to a personal @yahoo.com address and you would like to prevent that and force using company email [email protected] instead, you could add a check_recipient_access restriction to your main.cf:

 smtpd_recipient_restrictions =
     ...
     check_recipient_access hash:/etc/postfix/denied_recipients,
     ...
     permit

and then add a reject with a human readable reason into /etc/postfix/denied_recipients:

 [email protected]  REJECT  The CEO must be contacted using official <[email protected]> address.

(As I used hash: in my example, don't forget to postmap /etc/postfix/denied_recipients.)

---

Using transport(5) table for overriding Postfix built-in defaults

In order to make all [email protected] be delivered to [email protected] you can use transport_maps instead of smtp_generic_maps.

DESCRIPTION

The optional transport(5) table specifies a mapping from email addresses to message delivery transports and next-hop destinations. Message delivery transports such as local or smtp are defined in the master.cf file, and next-hop destinations are typically hosts or domain names. The table is searched by the trivial-rewrite(8) daemon.

This mapping overrides the default transport:nexthop selection that is built into Postfix.

Add transport_maps to your /etc/postfix/main.cf:

 transport_maps = hash:/etc/postfix/transport

And then add to /etc/postfix/transport one line for [email protected] altering the default transport:nexthop to virtual:[email protected]:

 [email protected]   virtual:[email protected]
 yahoo.com       :
 *               :

The other lines just states that no modification is done for yahoo.com and the rest, falling back to the default transport:nexthop behaviour.

Comments

[Esa Jokinen]

Your generic map starts to work as soon as you add yahoo.com in mydestination. However, like warned, that will brake all mail to that domain by making all [email protected] to local mailboxes available in local delivery and replying 550 5.1.1 aka User unknown in local recipient table for all other yahoo.com addresses.

[Server Fault]

Hrm.. I was going to use an entry in transports; eg; [email protected] procmail and then add local ceo user with a ~/.procmailrc. I did not consider mydestination = ...,yahoo.com. Not sure the transports approach will work.. still testing

[Esa Jokinen]

You were simultaneously heading to the same direction I was trying to guide you in my additional solution! Now my answer describes why the original suggestion didn't work and two different approaches.