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 Stefano Bagnara <ap...@bago.org> on 2005/09/02 19:27:15 UTC
isLocalUser behaviour (Was: Out of the box virtualhosting)
The only real change I/we need is to be able to check user presence in a
single call (this would allow many different virtualhosting solutions, but
we can discuss them after this).
Currently we run MailetContext.isLocalServer(domain) and in the following
call MailetContext.isLocalUser(local-part).
Having 2 different calls does not allow us to check users associated to a
specific domain.
We have 3 options:
1) change the isLocalUser documentation saying that you MUST provide the
full email address
1a) eventually allowing to use names without @ (the system will consider
automatically @localhost)
2) add a further method isLocalEmail(String local, String domain) or
isLocalEmail(String fullEmail) to the MailetContext
3) add a 2 parameter isLocalUser(String user, String domain)
This would replace the current client code:
mailetContext.isLocalServer(recipient.getHost()) &&
mailetContext.isLocalUser(recipient.getUser())
With
mailetContext.isLocalEmail(recipient)
IMHO this is a good improvement over the current API way to resolve local
users (double call) and this would allow us to implement automatic
virtualhosting support.
In solution 2) and 3) I would also deprecate the current isLocalUser since
it does not make much sense to check wether an user is local without
checking the domain first.
My vote goes for "1a)" if we plan to add this in 2.3.0 because it would be
totally backward compatible but for "2)" if we delay this change to 3.0.
IMHO implementation details can be discussed after this one.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: isLocalUser behaviour (Was: Out of the box virtualhosting)
Posted by "Kervin L. Pierre" <ke...@adevsoft.com>.
Stefano Bagnara wrote:
> We have 3 options:
> 1) change the isLocalUser documentation saying that you MUST provide the
> full email address
> 1a) eventually allowing to use names without @ (the system will consider
> automatically @localhost)
There can also be a 'defaultDomain' setting that
could be appended in place of 'localhost' maybe?
Regards,
Kervin
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: isLocalUser behaviour (Was: Out of the box virtualhosting)
Posted by Stefano Bagnara <ap...@bago.org>.
Cavan,
> Will the admin utilities be upgraded to allow us to specify
> the domain of a user when we add them?
> Will we be able to setup multi-domain boxes? bob@foo.com and
> bob@bar.com go to the same box as is the current behavior?
> If so, can bob@foobar.com go to a separate box? How would
> These are questions I'd like to know the answer to as a user.
> [...]
The change I've proposed does not provide what you are asking but it is a
needed step in that direction.
The change would allow easier management of virtualdomains by allowing us to
delegate the whole virtualdomain management to the mailets.
We probably could provide backward compatible mailets and a set of mailets
supporting your requests.
> Might want to talk to the IMAP folks about this as well
> since that is another feature that is salivated over by
> people like me.
>
> Cavan Morris
> User
I'm sorry but IMAP support is not ready to be bundled in 2.3.0. We should
follow the roadmap to 2.3.0 and start the work for 3.0.0 with the hope that
IMAP will see the light in the next major release.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: isLocalUser behaviour (Was: Out of the box virtualhosting)
Posted by Cavan Morris <ca...@epassporte.com>.
Will the admin utilities be upgraded to allow us to specify the domain
of a user when we add them?
Will we be able to setup multi-domain boxes? bob@foo.com and
bob@bar.com go to the same box as is the current behavior? If so, can
bob@foobar.com go to a separate box? How would this be configured and
administered? Perhaps delivery to a domain specific box should be
attempted first and if that is not found it would revert to a generic
box as is now the case. I think that this would be more consistent with
the current behavior than delivering to a default box (@localhost).
I would guess that the inbox dirs for the above situation could look
something like:
> ls
bob@foobar.com
bob@foo.com
with an alias from bob@bar.com to bob@foo.com
or
> ls
bob@foobar.com
bob@localhost
If all mail to bob@anydomain and not to bob@foobar.com was to go to bob
and we were to use the localhost default or default domain approach.
or
> ls
bob@foobar.com
bob
If all mail to bob and not to bob@foobar.com was to go to bob and we
were to continue to use inboxes without domains as the default.
These are questions I'd like to know the answer to as a user. Might
want to talk to the IMAP folks about this as well since that is another
feature that is salivated over by people like me.
Cavan Morris
User
Stefano Bagnara wrote:
>The only real change I/we need is to be able to check user presence in a
>single call (this would allow many different virtualhosting solutions, but
>we can discuss them after this).
>
>Currently we run MailetContext.isLocalServer(domain) and in the following
>call MailetContext.isLocalUser(local-part).
>Having 2 different calls does not allow us to check users associated to a
>specific domain.
>
>We have 3 options:
>1) change the isLocalUser documentation saying that you MUST provide the
>full email address
> 1a) eventually allowing to use names without @ (the system will consider
>automatically @localhost)
>2) add a further method isLocalEmail(String local, String domain) or
>isLocalEmail(String fullEmail) to the MailetContext
>3) add a 2 parameter isLocalUser(String user, String domain)
>
>This would replace the current client code:
>mailetContext.isLocalServer(recipient.getHost()) &&
>mailetContext.isLocalUser(recipient.getUser())
>With
>mailetContext.isLocalEmail(recipient)
>
>IMHO this is a good improvement over the current API way to resolve local
>users (double call) and this would allow us to implement automatic
>virtualhosting support.
>
>In solution 2) and 3) I would also deprecate the current isLocalUser since
>it does not make much sense to check wether an user is local without
>checking the domain first.
>
>My vote goes for "1a)" if we plan to add this in 2.3.0 because it would be
>totally backward compatible but for "2)" if we delay this change to 3.0.
>
>IMHO implementation details can be discussed after this one.
>
>Stefano
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>For additional commands, e-mail: server-dev-help@james.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: isLocalUser behaviour (Was: Out of the box virtualhosting)
Posted by Danny Angus <Da...@slc.co.uk>.
> IMHO this is a good improvement over the current API way to resolve local
> users (double call) and this would allow us to implement automatic
> virtualhosting support.
I agree. :-)
> In solution 2) and 3) I would also deprecate the current isLocalUser
since
> it does not make much sense to check wether an user is local without
> checking the domain first.
Also agree.
> My vote goes for "1a)" if we plan to add this in 2.3.0 because it would
be
> totally backward compatible but for "2)" if we delay this change to 3.0.
Agree.
+1 to 1a
(p.s. to the person who wanted a "default" domain, names without addresses
are legitimate email addresses, the RFC's say that they should be treated
as destined for the local domain, this translates literally to "localhost",
but I guess could be made to be configurable to any domain)
> IMHO implementation details can be discussed after this one.
Agree.
I agree with your approach to enabling virtual hosting in SMTP by
delegating more of the domain/destination decisions to the mailets.
The only concern that I have is related to matching this up with POP3
changes.
Any change that doesn't impose a naming convention and is backwards
compatible is OK by me.
d.
***************************************************************************
The information in this e-mail is confidential and for use by the addressee(s) only. If you are not the intended recipient (or responsible for delivery of the message to the intended recipient) please notify us immediately on 0141 306 2050 and delete the message from your computer. You may not copy or forward it or use or disclose its contents to any other person. As Internet communications are capable of data corruption Student Loans Company Limited does not accept any responsibility for changes made to this message after it was sent. For this reason it may be inappropriate to rely on advice or opinions contained in an e-mail without obtaining written confirmation of it. Neither Student Loans Company Limited or the sender accepts any liability or responsibility for viruses as it is your responsibility to scan attachments (if any). Opinions and views expressed in this e-mail are those of the sender and may not reflect the opinions and views of The Student Loans Company Limit
ed.
This footnote also confirms that this email message has been swept for the presence of computer viruses.
**************************************************************************
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org