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

Re: Setting up virtual domains correctly

Expand Messages
  • Viktor Dukhovni
    ... Why do you need to assume? All examples using indexed files are a mechanism to demonstrate the required table contents. You should know by now that all
    Message 1 of 8 , Apr 10, 2013
    • 0 Attachment
      On Wed, Apr 10, 2013 at 07:55:53AM -0700, Quanah Gibson-Mount wrote:

      > >This said, I would take a different approach:
      > ...
      >
      > Thanks Viktor, this looks interesting.
      >
      > I'm assuming I can do all of this via LDAP rather than flat files?

      Why do you need to assume? All examples using indexed files are
      a mechanism to demonstrate the required table contents. You should
      know by now that all tables are logically equivalent provided they
      return the same results for the same lookup keys.

      > We have customers with thousands of domains, and number of which may
      > be aliases for various of the defined domains, which is why we query
      > all of this information from LDAP. Any solution that requires using
      > flat files is a nonstarter.

      This said, not all tables are operationally equivalent. All the
      hoops jumped in my preferred configuration are designed to avoid
      having an LDAP *transport* table. The transport table should
      ideally be small, static and "indexed" (generated as a CDB or
      similar local database in a file).

      By rewriting users to mailstore-specific mailbox addresses, you
      at most need transport table entries for each mail store, not
      for each user. You can even do away with per-mailstore transport
      entries if you set:

      virtual_transport = lmtp
      # Adjust if necessary
      lmtp_tcp_port = 24

      and ensure that all the mailstore-specific domain-parts resolve
      in DNS. To that end you can rewrite users to:

      luser@... luser@...
      luser2@... luser2@...
      ...

      and avoid the "invalid" TLD if that's preferred. You can still
      disallow remote injection directly into the server domains, by
      various mechanisms (mostly make sure to not include them in
      relay_domains via parent_domain_matches_subdomains).

      Lots of ways to skin this cat... I am not a fan of LDAP with
      transport_maps, since this impacts queue-manager reliability
      and performance. Also rewriting is more robust against loops.
      Where-as forwarding the same address around based on transport
      tables risks inconsistent configuration leading to loops.
      If the per-user transport end-point is LMTP, the loop issue is
      less of a concern, since LMTP servers are not expected to ever
      forward mail.

      --
      Viktor.
    Your message has been successfully submitted and would be delivered to recipients shortly.