6 Replies Latest reply on Oct 11, 2005 10:09 AM by Andrew Oliver

    Feedback wanted on Virtual Hosts

    Andrew Oliver Master

      I originally sent this to Eric (one of our administrator dudes) at jboss... However I thought the group might be able to help too:

      One of the things I'm working on right now for JBMS is virtual hosts. Meaning one mail server handling mail for multiple domains.

      For mail transport, it is fairly straightforward. For authentication and delivery it is less so.

      Postfix requires you to map mail addresses to real accounts. Meaning
      andy@jboss.org maps to acoliver (UNIX account for instance)
      andy@jboss.com maps to andy (UNIX account for instance).

      We presently don't support vhosts but thats what I'm working on now. We do however allow you to utilize JBossAS login modules including LDAP/DB.

      I kind of don't like the mapping concept from an admistration standpoint (but I'm interested in your thoughts). It requires someone to maintain a mapping outside of their normal authentication structure.

      The reason this cannot work like http is that the SMTP/POP protocols do not pass the domain the user connected to (HTTP does).

      Possibilities for our implementation:

      0. mapping - same deal.

      1. restriction - user = emailaddress (user@domain.com). This would mean that andy could only be on jboss.org or jboss.com but not both.

      2. fixed rule - accounts = user{seperator}domain. Meaning andy@jboss.com would be "andy-jboss.com" and andy@jboss.org would be "andy-jboss.org" or possibly "andy-jbosscom" "andy-jbossorg"

      3. password - andy@jboss.org and andy@jboss.com both map to andy. The accounts are differentiated by password. This means both users have to pick different passwords. This will likely mean that the authentication will be routed to one login module then fail over to another (up to "n" where n = number of domains * x, x = number of login modules per security domain [usually 1])

      4. dynamic rewrite - a regular expression rewrites the account into the address and vice versa.

      What do you think would be the most reasonable and most admisterable (if that is a word) option or combination of options? Which is "best" (highest priority)? Why?

        • 1. Re: Feedback wanted on Virtual Hosts
          Damon Sicore Novice

          From an admin point of view the /etc/aliases combined with domaintable and genericstable are really easy. The only thing that is confusing about them is telling sendmail to use them in the first place.

          As I admin my 20 or so domains, with a hundred or so users, which have 0-30 additional aliases, the above three files are very easy to manage. Whatever you do, you will need more than just andy@domain. Users and admins will want myfriendandy@domain and about 10 other aliases which don't necessarily map to a unix account of the same name.

          • 2. Re: Feedback wanted on Virtual Hosts
            Andrew Oliver Master

            To me aliases are different from virtual hosts. We'll have both.

            • 3. Re: Feedback wanted on Virtual Hosts
              Damon Sicore Novice

               

              "acoliver@jboss.org" wrote:
              To me aliases are different from virtual hosts. We'll have both.


              Right, but, the reason I'm even mentioning aliases is that I don't have to explicitly declare/map them for every domain (vhost) that they exist on unless the user wants their mail to originate from a domain different than the default domain. So, whatever the rules are for creating an alias, I don't want to have to worry about vhosts.

              The
              1. restriction - user = emailaddress (user@domain.com)
              and
              2. fixed rule - accounts = user{seperator}domain.
              and
              3. password - andy@jboss.org and andy@jboss.com both map to andy.


              ... seem to imply that I'd have to do extra work when I want to add an alias that spans vhosts. I don't want extra work.

              • 4. Re: Feedback wanted on Virtual Hosts
                Andrew Oliver Master

                okay so from your perspective addresses are all aliases and multiple aliases are mapped to an account. The accounts are restricted such that there can only be one "acoliver" account but andy@jboss.org, acoliver@jboss.org and andy@jboss.com could all be mapped to it. Is that correct?

                • 5. Re: Feedback wanted on Virtual Hosts
                  Damon Sicore Novice

                   

                  okay so from your perspective addresses are all aliases and multiple aliases are mapped to an account.


                  I'd say that is safe to say. However, as you know, aliases can also be groups of accounts or other aliases.

                  The accounts are restricted such that there can only be one "acoliver" account but andy@jboss.org, acoliver@jboss.org and andy@jboss.com could all be mapped to it.


                  Accounts, by definition, imply that "there can be only one." I mean, can you have an account that is really "two" accounts on a unix machine (i.e., multple home dirs and such for a single account)? Hell, maybe.

                  My point is, that I can have all those accounts (andy@jboss.or, acoliver@jboss.org and andy@jboss.com) by adding aliases in a single location with acceptable defaults (i.e., outbound vhost defaults to MASQUERADE_AS(`jboss.org') )




                  • 6. Re: Feedback wanted on Virtual Hosts
                    Andrew Oliver Master

                    Okay so I'm thinking you're right. I'm thinking:

                    account -> default address
                    account -> aliases
                    default address ~ alias
                    (the direct mapping is needed for "verify-identity" setting which prevents you from sending email as me once authenticated)

                    how aliases map to distribution lists is a different matter, but:

                    alias -> mailbox || alias -> address[]

                    This seems workable....