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]>
