On Thu, 29 Nov 2012, Viktor Dukhovni wrote:
In my experience, public facing email domains for organizations
with complex email requirements are almost almost best implemented
as virtual alias domains. This adds a layer of indirection between
the outside view of an email domain (everyone is just [email protected])
and the inside view (rewrite to [email protected]).
This is certainly an elegant solution. It's not a decision I'd be
empowered to make however, and also we might run into problems when
customers try to send mail to each other.
I did manage to solve it however, and in the end it was really quite
trivial.
I generated a file that looks like this:
[email protected] relay:[[email protected]]
[email protected] relay:[[email protected]]
[email protected] relay:[[email protected]]
...
and ran it through postmap. I now have a transport table I can also use
as a relay_recipient_map.
Then I created another file with:
example.com relay:[[email protected]]
* smtp:
Now I have two transport tables which I can make transport_maps, with only
the first used as recipient_maps so that the example.com catch-all doesn't
get used for recipient validation.
Of course, we will probably end up using something more elegant than
file-based data in the end, but it was the principle I needed to get
right.
Cheers,
Geoff.
