I haven't actually read all of this yet.. (I will, don't worry) but one of the issues is that we'd like people's login username to == their mailaddress username for each domain. I reckon that if we could detect the hostname that users [thought they] were connecting to for POP3 then the problem would start to evaporate.
> -----Original Message----- > From: Noel J. Bergman [mailto:[EMAIL PROTECTED]] > Sent: 27 April 2002 21:58 > To: James-User Mailing List > Cc: James-Dev Mailing List > Subject: Virtual hosting redux, smtp mapping, etc. > > > 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]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
