On 3/20/2013 1:05 PM, Jon A. wrote: > I've a number of "nobody" type aliases that I map in transport_maps > to the discard service. Our incoming MX boxes also reject mail > based on the valid userlist from our internal mail server. > > It would appear that the relay_recipient_maps is applied before > transport, thus anything listed in transport that isn't also in > relay_recipients_maps bounces. > > The obvious solution would be to add the various "nobody" users to > the recipient table, however that's generated off box and moved > over/rebuilt via remote ssh cron job. I'd have to maintain the > transport list in two places for that box to push the complete list > to all our incoming mx servers. > > My second thought is to maintain two relay_recipient_maps table > entries, something like: > > relay_recipient_maps = hash:/etc/postfix/primary_mail_recipients, > hash:/etc/postfix/transport > > As the documentation indicates it only cares if a recipient lookup > succeeds (and not the return value), is it reasonable to expect I > could just use the transport_maps file both cases without issue? > Right now transport is pretty simple but the documentation in the > transports file indicates wildcards are possible. Would this be a > bad choice to implement not knowing what may ultimately end up in > this file in the future? > > Are there other best practices that better solve this problem?
You can reuse a transport map as a relay_recipients_map, but better to name it something else so you don't accidentally add eg. a hotmail transport and become an open relay. ## main.cf transport_maps = # in your case, the transport file might be empty # but "postmap transport" it anyway. hash:/etc/postfix/transport, # relay_transport contains relay recipients hash:/etc/postfix/relay_transport relay_recipients_maps = hash:/etc/postfix/primary_mail_recipients, hash:/etc/postfix/relay_transport An alternative is to use a simple Makefile to build both files from a common list of names. Google has examples. -- Noel Jones
