Multiple Domains

[edaugherty]

Are we going to attempt to implement multiple domain support? This is something that I have received a lot of positive feedback about in JES. It seems to be a feature that people see as neccessary, and something that can be very hard to do if you do not think it through early on.

Thoughts?

[acoliver]

I'd posted a reply to this before, but that message (as well as my ability to login) has disappeared. I'll try to recreate it.

Do you have an interest in helping out with some of this? Especially the GUI stuff. Take a look at my thoughts so far: http://linuxintegrators.com/blog/acoliver/code/?permalink=0131.html

I am interested in contributing to this project. I read what was on your website with respect to building a GUI out of XUL, and while I have no experience whatsoever with XUL, my gut feeling is that a nice web GUI using Struts/Tiles should provide all the layout capabilities you need and still hide the complexity of the underlying jmx-console.

Additionally, I think a nice addition to this project would be a webmail client for use by end users. This would give end users a way to use the built in anti-spam features (edit/view addresses on the whitelist and blacklist and deny/approve emails on the greylist a la TDMA) as well as give more visibility into the project.

Nathan

[acoliver]

Please elaborate. Presently the SMTP stuff allows you to specify which domains are "local" and considers everything else "remote"...

[edaugherty]

Multiple domain support can manifest itself several ways. The basic idea is that you want a single mail server to handle mail for multiple domains (@mydomain.com and @yourdomain.com).

Sendmail supports this by allowing you to map virutal addresses to a single local user. So I could edit virtualusertable to say [e-mail] maps to edaugherty. Or I could say *@mydomain.com maps to edaugherty. However, there is only ever one edaugherty user for the machine. You could of course map [e-mail] to edaugherty and [e-mail] to edaugherty2 or some other user.

With my standalone mail server (JES), I defined users as the username and domain. So a username maped direcdly to a mailbox. The limitiation is that when you login to the POP3 server, you put '[e-mail]' as the username. JES does not support any real virutal addresses, so it could not implement the same solution as sendmail.

I'm sure there is some 'third way' to do it, but the two soltions I'm aware of is map addresses to local users, where the local username is unique, or include the domain in the local user name (making it unique).

Something that ties in with this is validation of recipients. Are we going to verify that mail to a user at a local domain really exists? If so, we need to resolve all virtual addresses, etc. I looked over the processAuth method but I must confess I was a little confused. It looks like it validates that a user is logged in before relaying (which is good!), but the check for local delivery only seems to check the server name and not the entire list of local domains supported (which seem to be defined in the JMSListener as OnServerDomains). The Verify Identity check has me lost.

[acoliver]

I think we should support the multiple domains, but if you ask me we should put that off. I want to nail "must have" first and "nice to have" later. I'll look harder at the verify and checkauth. I probably mostly ripepd off JAMES only unf*cked their code. Don't assume that code is right, I don't think I have a unit test for it so its quite possibly wrong. Feel free to rip it out and change it. One thing I don't want is to keep an open relay. I'd like to make security a priority though and maybe beep the speaker with big red blinking letters if they even try to make it an open relay. ;-)

[jmc286642]

When combined with the interaction of the features of the JBoss Application Server, it will be one of the most powerful email application solutions to date.
--Andrew C. Oliver

For the above to be truly true Mail Services 1.0 needs to support multiple domains. JBoss Mail Services should offer all of the functionality of the traditional UNIX/Linux mail offerings, but it should also be combined with a relative ease of use. Many will not be able to use JBoss Mail Services (JBMS) unless it robustly supports multiple domains.

As for when JBMS supports multiple domains, sooner is better than later. Many would rather see a promising project work out a vital function early on, rather than later in its life. Lack of easy virtual/multiple domain implementation in JAMES 2.X is why I personally haven't rolled that solution out on our production server.

Lastly, my thanks for your work!

[negge]

I'd posted a reply to this before, but that message (as well as my ability to login) has disappeared. I'll try to recreate it.

Do you have an interest in helping out with some of this? Especially the GUI stuff. Take a look at my thoughts so far: http://linuxintegrators.com/blog/acoliver/code/?permalink=0131.html

I am interested in contributing to this project. I read what was on your website with respect to building a GUI out of XUL, and while I have no experience whatsoever with XUL, my gut feeling is that a nice web GUI using Struts/Tiles should provide all the layout capabilities you need and still hide the complexity of the underlying jmx-console.

Additionally, I think a nice addition to this project would be a webmail client for use by end users. This would give end users a way to use the built in anti-spam features (edit/view addresses on the whitelist and blacklist and deny/approve emails on the greylist a la TDMA) as well as give more visibility into the project.

Nathan

[acoliver]

Can you start working on a webmail client? I think that is higher priority than the admin stuff UI-wise until the underlying plumbing for persistent changes to descriptors and a semi-transactional deployment scanner/main deployer is done. That would require some pretty intense JBoss knowledge for anyone willing to do it (but once thats done, a user-friendly UI for admins is important -- remember our competition in that area is MS Exchange!)