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? [EMAIL PROTECTED] and
[EMAIL PROTECTED] go to the same box as is the current behavior? If so, can
[EMAIL PROTECTED] 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
[EMAIL PROTECTED]
[EMAIL PROTECTED]
with an alias from [EMAIL PROTECTED] to [EMAIL PROTECTED]
or
> ls
[EMAIL PROTECTED]
[EMAIL PROTECTED]
If all mail to [EMAIL PROTECTED] and not to [EMAIL PROTECTED] was to go to bob
and we were to use the localhost default or default domain approach.
or
> ls
[EMAIL PROTECTED]
bob
If all mail to bob and not to [EMAIL PROTECTED] 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
