Why not just adopt a naming convention for POP3 logins? Use a mailet to
convert a message addressed to "[EMAIL PROTECTED]" to "me..mydomain.com".
This lets us cope with an essentially flat POP3 namespace by converting our
hierarchical smtp addresses to a structured flat form.
Of course, the user would have to cope with having a login that is
different from their address, but most users would not realise that this
was unusual.
ADK
--------------------------------------------
There is no magic.
"Noel J.
Bergman" To: "James-User Mailing List"
<[EMAIL PROTECTED]>
<noel@devtech. cc: "James-Dev Mailing List"
<[EMAIL PROTECTED]>
com> Subject: Virtual hosting redux, smtp
mapping, etc.
28/04/2002
08:57
Please respond
to "James
Users List"
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]
>
-----------------------------------------------------------------------------------------------
Have you seen our website?.... http://www.vodafone.co.nz
CAUTION: This correspondence is confidential and intended for the named recipient(s)
only.
If you are not the named recipient and receive this correspondence in error, you must
not copy,
distribute or take any action in reliance on it and you should delete it from your
system and
notify the sender immediately. Thank you.
Unless otherwise stated, any views or opinions expressed are solely those of the
author and do
not represent those of Vodafone New Zealand Limited.
Vodafone New Zealand Limited
21 Pitt Street, Private Bag 92161, Auckland, 1020, New Zealand
Telephone + 64 9 357 5100
Facsimile + 64 9 377 0962
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
