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 u...@example.com)
and the inside view (rewrite to u...@users-mailbox-domain.example.net).
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:
corpora...@example.com relay:[corporate_m...@example.com]
corpora...@example.com relay:[corporate_m...@example.com]
corpora...@example.com relay:[corporate_m...@example.com]
...
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:[customer_m...@example.com]
* 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.
