Loading ...
Sorry, an error occurred while loading the content.

Re: Relaying based on recipient without maintaining two lists

Expand Messages
  • Geoff Shang
    ... 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
    Message 1 of 3 , Nov 29, 2012
    • 0 Attachment
      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 user@...)
      > and the inside view (rewrite to user@...).

      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:

      corporate1@... relay:[corporate_mail@...]
      corporate2@... relay:[corporate_mail@...]
      corporate3@... relay:[corporate_mail@...]
      ...

      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_mail@...]
      * 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.
    Your message has been successfully submitted and would be delivered to recipients shortly.