This is a long thread, and rather than respond to each email, I'll just throw my thoughts into a single spurt...
a) yes, POP3 doesn't support domains, and a "mapping" mailet could be clever short-term solution. In theory we could just provide a parameter to indicate the style of mapping, but I really see this as a short-term solution because... b) while mapping let's you do virtual hosting, it's not scalable. i) it would quickly become unmanageable as the admin tools do not let you restrict the users to a given domain at a time, ii) you need to distribute authority so [EMAIL PROTECTED] can manage all the accounts for domain1.com, iii) you're still stuck editing the config.xml and restarting everytime you need to add/remove a domain, iv) you might want to support disparate lists, so domain[1-10].com are in the database, but this-isp.com is pulling from an LDAP repository or something like that. c) the JDBCAlias was never meant for this kind of stuff... it's just a JDBC/James equivalent to the forward file in sendmail, aliasing one address to another. not a big deal, just don't think it's related to this discussion. If someone wants to put forward a mailet that can do this mapping (or possibly support multiple mappings), with good documentation on how that mailet works and how to setup virtual hosting this way with all the caveats, I'd be interested in looking it over. However, I still think we need a more complete virtual hosting solution for the long-term (however long in the future that is). What I was thinking is moving the list of servernames to a new kind of repository, so then you could use the admin tool (remote telnet for now) to edit not only users, but also domains (and we'd remove the way we currently configure the domains, or at least not require it). Then you could set whatever settings we determine necessary for each domain (the hostname(s), who can administer it, what happens if an email arrives for this domain that doesn't match a user, etc...). Anyway, still kind of fledging, but for a scalable virtual hosting solution, I think this approach is necessary. Still have to figure out how to add this without making it hard for the person just administering a basic mail server. -- Serge Knystautas Loki Technologies - Unstoppable Websites http://www.lokitech.com/ Noel J. Bergman wrote: > I was reading Jeff Keyser's useful message, > http://www.mail-archive.com/james-user%40jakarta.apache.org/msg01543.html, > regarding virtual hosting and had some thoughts. Hopefully, folks will > comment on the below, and indicate if/where I am being naive, or if this > offers a pragmatic and workable solution. > > I understand the POP problem, which is that a user name is a user name is a > user name, with no knowledge of domains. Fine. That is on the POP side. > However, on the SMTP side, we know the target domain. > > Jeff Keyer's solution, similar to that used elsewhere, is to create local > mailboxes for users on a single "domain." His users are told how to login > to the designated POP3 server to pick up their e-mail. However, on the SMTP > side, his solution is to use mailets to first select by domain, and then map > (forward) from a particular user at that domain to another destination. His > example is to forward to a defined mail user at the local domain, but > generally speaking, it is just a forwarding operation. > > It seems to me that rather than have to manage this mapping by adding new > mailets via the config.xml file, there could be a data driven mapping: > [USER, DOMAIN] -> FORWARD. > > We can't just add a domain column to the existing user table. The primary > key in the user table is username, which is the POP3 identity. We need a > table whose primary key is [USER, DOMAIN]. Effectively, I view the existing > user table as the POP3 table, and propose an SMTP user table, which maps to > either a local address or a remote address. > > This separates users (SMTP) and mailboxes (POP3). Adding a new user means > saying where to deliver SMTP messages. That can be a forwarding address or > a local mailbox. Adding a forward means simply adding a mapping > (a-forwarded-address@mydomain -> forwarding-address). In the case of a > forward, we don't even need an entry in the user table, although we'd have > one in the case of a temporary forward for a local user. Adding a local > user means creating both an SMTP user identity (a-user@mydomain -> > alocaluser) and a POP3 identity (alocaluser). > > A mailet could perform the [user, domain]->forward mapping, and feed it > through the rest of the current transport processor. Local delivery > (post-mapping), remote delivery, etc., could remain unaffected. > > When an SMTP message arrives, we map it via the [user, domain] mapping. The > mapped address will then be given back to the processing chain, resulting in > delivery to a mailbox, forwarded address, mailing list, whatever, just as if > that address had been received. > > If an SMTP message whose [user, domain] is not in the mapping table, it is > an error if the domain is in the table, or a remote host (relay) if the > domain is not in the table. Messages from anywhere for domains in the > mapping table would be accepted; only messages from the approved sources > would be accept for domains not in the mapping table. This is at least > similar to the RecipientIsLocal, HostIsLocal, etc., mailet processing > already done; I'm not familar enough to be sure, but I suspect that the > mapping mailet could set things up so that those other filters could operate > normally with little change. > > Thoughts? Flames? Barely veiled insinuations? > > --- Noel -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
