1 Reply Latest reply on Jul 25, 2005 4:31 PM by Michael Barker

    virtual domains

    Thorsten Kunz Novice

      Hi there,

      I just started to play around with the JBMAIL system a few days ago and I think it has a hugh potential. :)

      But I have a question I could't find answer to it in the wiki:

      Are you going to seperate local domains from virtual domains or how are you going to hande multidomains in general? In other un*x based MTAs (e.g. qmail) the reason for having local and virtual domains is so that the locals can be delivered to system users mailboxes (may it be ~/.maildir or some spools) and virtuals are going into a different storage system (e.g. vpopmail) where they can be retrieved via pop/imap. Since JBMAIL is not a MTA bound to un*x or windoze you don't have "real" system users by default. Would't it seem more native to the approch to create a unified multirealm system where a realm may have n-domains associated with it as well as n-users in it. In a realm a username has to be unique as well as a domain name. Two realms can have the same accountnames but domains need to be unique in the entire system.

      Since its a little abstract here is a little sample structure:

       mailbox_impl="com.jboss.mail.x.mailbox.HBImpl" //user Hibernate implemantation to store mailboxes
       userrepos_impl="com.jboss.mail.x.userrepository.XMLFileImpl"> //get useraccounts from this file
       mailbox_impl="com.jboss.mail.x.mailbox.SystemMaildirImpl" //use a .maildir implementation to store the mailbox
       userrepos_impl="com.jboss.mail.x.userrepository.ShadowPasswordImpl"> //use the system account implementaion to get accountnames for this realm

      Just a very basic idea. Mail routing, header rewriteing and other fancy stuff could be configured on a per realm, per domain or per user base. User accounts/credentials could also be stored different per realm since it has only a well defined interfaces and implementations could ba a simple xml file, ldap, unix systemaccounts, etc... same is true for the mailboxes but this is allready in the makeing as far as I can see.
      For user authentication or to receive a mail a protocol (e.g. SMTP) could parse the domain part of a username like zoe.jane@localhost.com and ask a realm manager if there is a realm for the domain like this:
      RealmIF realm = realmManager.getRealmByDomain(localhost.com)
      and if realm != null try to get an user interface
      UserIF user = realm.getUserByName(zoe.jane);
      if user != null we know the user is ok and maybe get his mailbox, password or other attributes our protocol may need
      MailboxIF mailbox = user.getMailbox()

      It would also eliminate "alias domains" since all domains that are associated with a realm are "real" and are able to receive, send, authenticate the users in the realm (depending in the way the interfaces/configurationattributes are designed this could change and all but 1 domain in a realm would be "aliases" with different treatment...).

      A mailservice hosting provider would be able to use any userrepository implementation to hook one of his customers hosted realms with domain ldapuser.com up to his customers existing LDAP server and use a local storage engine to store all the users mail on his ueberstoragearray. Tadaaa, his customer would be able to have a nice and neat hosted mailsolution available and the only thing the customer needs to maintain is his good 'ol ldap server to create/modify users.

      Don't know if this makes sense or not but the separation of local and virtual domains is something that bothered me so many times in the past and could be done so nicley if you just use different storage/repository implementations for users and mailboxes. :)

      Cheers, Thorsten

        • 1. Re: virtual domains
          Michael Barker Apprentice

          We definitely want to do Virtual Domains:


          What you have specified has merit and in concept is largely how would invisage it working (Andy speak up I am talking nonsense). However we would probably use MBeans to perform the configuration. The Realm (or DomainGroup or whatever you would like to call the logical aggregation of domains) would reference configured instances of the appropriate User Repository and Mailbox Manager. This would allow reuse instances across different realms.

          Rather than have the concept of a Realm Manager we would probably use a MailListener Chain ("RoutingChain" perhaps) would would have references to all of the Realms and associated delivery queues (either one listener per domain or a single listener that references all of the domains). The SMTP protocol would the push the mail to the RoutingChain which deliver it to the approriate local domain(s) and/or pass it to the remote delivery queue. Protocols like POP would probably be bound to a single Realm and lookup the associated User Repository and Mailbox Manager.

          Interestingly enough probabaly 85% of the code to make this happen are already there. Its mostly a case sorting out configuration.