You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by "Noel J. Bergman" <no...@devtech.com> on 2002/04/27 22:57:39 UTC
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Virtual hosting redux, smtp mapping, etc.
Posted by Danny Angus <da...@thought.co.uk>.
> However, I still think we need a more complete virtual hosting solution
> for the long-term
[snip]
> 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.
+1 this sums up my feelings too, although we could, in fact can, map,
mapping alone isn't enough for a true vhost solution, we also need to have
per domain postmasters, mailet containers, and administration log-ins to
name a few.
d.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Virtual hosting redux, smtp mapping, etc.
Posted by Serge Knystautas <se...@lokitech.com>.
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 bob@domain1.com 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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Virtual hosting redux, smtp mapping, etc.
Posted by "Noel J. Bergman" <no...@devtech.com>.
> > The POP3 protocol does not have a domain name; there is nothing
> >to "detect" unless you impose a convention for the login name.
> yes thats exactly what the problem is.
No, I maintain that these are separate and orthogonal issues. SMTP knows
about users and domains, POP knows about mailboxes. There is no agreed upon
solution for adding "domains" to POP3, other than conventions; the current
system supports the conventions. What we need to address is the SMTP
delivery issue.
Consider the aforementioned example, which used the config.xml file. A
separate mailet is installed for each address. Those addresses are
forwarded to other addresses for processing. My solution moves that map
into a standard James structure (a table for JDBC use, serialized map for
file system), supported by a mapping mailet and a change in the user
management tools, rather than an ad hoc solution that requires updating
config.xml for each new address.
Look at JDBCAlias, for example.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Virtual hosting redux, smtp mapping, etc.
Posted by Danny Angus <da...@thought.co.uk>.
> > 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.
>
> The POP3 protocol does not have a domain name; there is nothing
> to "detect"
> unless you impose a convention for the login name.
yes thats exactly what the problem is..
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Virtual hosting redux, smtp mapping, etc.
Posted by Lindsay Smith <li...@wapdat.com>.
-----Original Message-----
From: Noel J. Bergman [mailto:noel@devtech.com]
Sent: 28 April 2002 05:42
To: James Users List
Subject: RE: Virtual hosting redux, smtp mapping, etc.
> 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.
The POP3 protocol does not have a domain name; there is nothing to "detect"
unless you impose a convention for the login name.
> one of the issues is that we'd like people's login username
> to [equal] their mailaddress username for each domain.
Mail addresses don't map 1:1 with POP3 identities. I may have, and in fact
often have, multiple e-mail addresses funnel into a single POP3 mailbox.
Other addresses may exist for the sole purpose of contacting some bit of
mailet programming, e.g., a list address or monitor.
Actually, it looks as if a good chunk of this is already done. :-) The
[user, domain] -> address mapping looks like what Serge Knystautas had in
mind with the JDBCAlias mailet
(http://jakarta.apache.org/james/javadocs/org/apache/james/transport/mailets
/JDBCAlias.html), but it doesn't appear supported by the user management
tools. I am guessing that his source address column is assumed to have the
domain embedded within it.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Virtual hosting redux, smtp mapping, etc.
Posted by "Noel J. Bergman" <no...@devtech.com>.
> 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.
The POP3 protocol does not have a domain name; there is nothing to "detect"
unless you impose a convention for the login name.
> one of the issues is that we'd like people's login username
> to [equal] their mailaddress username for each domain.
Mail addresses don't map 1:1 with POP3 identities. I may have, and in fact
often have, multiple e-mail addresses funnel into a single POP3 mailbox.
Other addresses may exist for the sole purpose of contacting some bit of
mailet programming, e.g., a list address or monitor.
Actually, it looks as if a good chunk of this is already done. :-) The
[user, domain] -> address mapping looks like what Serge Knystautas had in
mind with the JDBCAlias mailet
(http://jakarta.apache.org/james/javadocs/org/apache/james/transport/mailets
/JDBCAlias.html), but it doesn't appear supported by the user management
tools. I am guessing that his source address column is assumed to have the
domain embedded within it.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Virtual hosting redux, smtp mapping, etc.
Posted by Danny Angus <da...@thought.co.uk>.
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:noel@devtech.com]
> 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:
<ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>