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 (JIRA)" <se...@james.apache.org> on 2006/05/24 20:57:31 UTC
[jira] Created: (JAMES-508) Make MailetContext.isLocalUser domain
aware
Make MailetContext.isLocalUser domain aware
-------------------------------------------
Key: JAMES-508
URL: http://issues.apache.org/jira/browse/JAMES-508
Project: James
Type: Improvement
Components: James Core
Reporter: Stefano Bagnara
Assigned to: Stefano Bagnara
Fix For: 2.4.0
Trying to resume an old task:
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.
The proposed solution is:
1) change the isLocalUser documentation saying that you MUST provide the
full email address
2) eventually allowing to use names without @ (the system will consider
automatically @localhost)
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.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [jira] Commented: (JAMES-508) Make MailetContext.isLocalUser
domain aware
Posted by Stefano Bagnara <ap...@bago.org>.
Noel J. Bergman (JIRA) wrote:
> [ http://issues.apache.org/jira/browse/JAMES-508?page=comments#action_12413193 ]
>
> Noel J. Bergman commented on JAMES-508:
> ---------------------------------------
>
> I don't have a problem with adding isLocalEmail to eventually replace isLocalUser, but we should keep isLocalServer, since there are some checks to just see if that domain is locally hosted.
Sure!
Now I changed the default isLocalUser to also check for "@" presence,
and use @localhost if not present, then forwards the call to the new
isLocalUser(MailAddress) that check both domain and user.
isLocalServer("localhost") always return true.
We already had the "localhost" hardcoded elsewhere, so I think I didn't
add any issue with this.
Upgrading current calls to isLocalUser to the full username we now are
only a few steps to a modular virtual hosting support.
Maybe I should change the new isLocalUser to isLocalEmail like you said.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Virtual User Tables
Posted by Stefano Bagnara <ap...@bago.org>.
Noel J. Bergman wrote:
> Actually, the virtual user code is just about what it ought to be, although
> what I proposed earlier would be a useful change. A few discussions that
> haven't been implemented are largely because some people just don't
> understand how SMTP and POP3 work. For example, the POP3 RFC says:
>
> USER name
> Arguments:
> a string identifying a mailbox (required), which is of
> significance ONLY to the server
>
> It need *NOT* be the user's e-mail address. We could look at expanding the
> range of possible mailbox identifiers, but there is no need.
I agree: in fact we currently don't use the email address but tha name
of the mailbox (often the localpart of the email address).
I also think that we should at least support a "fullemail" accounts
option. This would be without configuration and would allow to create
users using the full email address and check their mail separately using
"USER fullemail" via POP3. I would have lost much less hours replying to
users of this list if we had a component or a configuration for this
easy to understand, easy to implement scenario.
But you know I don't like features themselves, I instead prefer to
refactor the code and to expose services that allow us to modularize an
aspect... [continue...]
> This is not the problem with JAMES-426. The issue with JAMES-426 is that it
> neither takes into account that we can have non-JDBC virtual tables, nor the
> fact that we can have multiple virtual user tables. If implemented, it
> would, at best, be a temporary solution for a sub-set of users.
>
> Exposing a virtual user mapping service, and then querying that service,
> would resolve both issues.
>
> --- Noel
About http://issues.apache.org/jira/browse/JAMES-426 I assigned it to
me, and I explained that I don't like the proposed solution itself, and
I started working on a modular way to implement it. My first comment
explain the first part of the refactoring.
Btw isLocalUser does not (and will never do) take in consideration the
whole spooling and the possible AbstractVirtualUserTable,
AbstractRedirect, AbstractNotify, ToRepository and any other mailet that
allow to do something locally even with an email address not associated
to a local user.
This is in part related to the fastfailing for rcpts just proposed by
Norman: Imho we can add that handler, but it should be optional, and
should be carefully described that the handler is not aware of the full
processing but of the only virtualuser table.
Unfortunately you don't know if an email address is valid or not until
you process the full processors/matchers/mailets.
I agree we should modularize and move to top level service the most
important mailet services (like the virtusertable you propose).
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Virtual User Tables
Posted by Stefano Bagnara <ap...@bago.org>.
Sorry Noel,
After a second read I understand you're proposing something new
(different). I'm just a bit bored of too much discussions and no code
(did you notice this? ;-) ) that I undervalued your statements.
Is what you propose a service like:
public class RewritingService {
public MailAddress[] rewrite(MailAddress address);
}
or even:
public class RewritingService {
public MailAddress[] rewrite(MailAddress[] addresses);
}
The last give us more option to optimize, but less control.
At a first thought I prefer the first.
Furthermore, if we use a single rewrite per james instance we can create
a service and a top level component, otherwise we should create a store
for named rewriting services.
Our JamesUsersRepository would provide both services: UsersRepository
and RewritingService (for the aliasing forwarding stuff).
Stefano
Noel J. Bergman wrote:
> Stefano Bagnara wrote:
>
>> Noel J. Bergman wrote:
>>> That requires a bit of thought, rather than rushing into coding
>
>> I have lost the count of discussions with no end, with no conclusions
>
>> I'm sure I can find discussions about virtual users at least 3 years old
>
> Actually, the virtual user code is just about what it ought to be, although
> what I proposed earlier would be a useful change. A few discussions that
> haven't been implemented are largely because some people just don't
> understand how SMTP and POP3 work. For example, the POP3 RFC says:
>
> USER name
> Arguments:
> a string identifying a mailbox (required), which is of
> significance ONLY to the server
>
> It need *NOT* be the user's e-mail address. We could look at expanding the
> range of possible mailbox identifiers, but there is no need.
>
> This is not the problem with JAMES-426. The issue with JAMES-426 is that it
> neither takes into account that we can have non-JDBC virtual tables, nor the
> fact that we can have multiple virtual user tables. If implemented, it
> would, at best, be a temporary solution for a sub-set of users.
>
> Exposing a virtual user mapping service, and then querying that service,
> would resolve both issues.
>
> --- Noel
>
>
> ---------------------------------------------------------------------
> 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: Virtual User Tables
Posted by Stefano Bagnara <ap...@bago.org>.
Serge Knystautas wrote:
> On 5/26/06, Stefano Bagnara <ap...@bago.org> wrote:
>> Is what you propose a service like:
>>
>> public class RewritingService {
>> public MailAddress[] rewrite(MailAddress address);
>> }
>
> Just to throw it out there... one thing that makes sendmail rather
> strong is that since it's aliases are quite structured, it can know
> (and thus reject during SMTP protocol) recipients that it cannot
> handle for authoritative domain. So perhaps add both a rewrite() and
> a handles() method?
Sendmail merges aliases, virtualusertable, users entries to fill in a
single map for the matching.
We can't do this because we have mailets.
Let's say I have this mailet as my first mailet:
<mailet match="SenderIsRegex=.*a.*5.*3@.*foo.*\.com" class="ToRepository">
..repository infos..
</mailet>
In the SMTPHandler we are not able to understand that the mailet will
introduce some sort of whitelist for particular senders.
If we want to provide full fastfailing to the SMTPHandler we ask the
users to move much of their logic from Mailets processed by the
SpoolManager to Handlers processed by the SMTPServer.
I could also have mailets that allow only specific combinations of
sender/recipients and so on.
So we can support facilities for site administrators to manually insert
"filters" in the SMTPhandler to fastfail, but we'll never automagically
do that if we don't remove the Mailet support.
A middle step would be the "in-handler" processor: add a processor that
is executed after the data is closed (as a MessageHandler) that simply
run a full Processor (defined in the handler configuration, with it's
own spoolrepository) and if the message is GHOSTED consider it a
succesfull delivery, if the message is sent to ERROR it can reply an
SMTP error to the data.
SMTP specifications says that a similar process should take a small
amount of time (to avoid duplicate send).
This would not give us fastfail at MAIL or RCPT commands but would give
an administrator one more level of control.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: Virtual User Tables
Posted by "Noel J. Bergman" <no...@devtech.com>.
Serge Knystautas wrote:
> one thing that makes sendmail rather strong is that since
> it's aliases are quite structured, it can know (and thus
> reject during SMTP protocol) recipients that it cannot
> handle for authoritative domain. So perhaps add both a
> rewrite() and a handles() method?
Something like that, yes. We have the same notion in our scheme, except
that it currently results in delivery notices, since we can't do it
in-protocol.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Virtual User Tables
Posted by Serge Knystautas <sk...@gmail.com>.
On 5/26/06, Stefano Bagnara <ap...@bago.org> wrote:
> Sendmail merges aliases, virtualusertable, users entries to fill in a
> single map for the matching.
>
> We can't do this because we have mailets.
Sure, I just wanted to bring up the idea.
Maybe a flag (per hostname) to say whether to be rigorous on what
recipients you accept? So maybe @notices.lokitech.com can receive any
random recipient, but I'm only going to accept @lokitech.com only if
it's in a user table?
I don't know... I always thought this made it easier for spammers to
figure out who to send to, but I guess they don't care about what
would require more programming. You guys know better whether this
direction has any merit in it.
--
Serge Knystautas
Lokitech >> software . strategy . design >> http://www.lokitech.com
p. 301.656.5501
e. sergek@lokitech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Virtual User Tables
Posted by Norman Maurer <nm...@byteaction.de>.
Am Freitag, den 26.05.2006, 15:02 +0200 schrieb Stefano Bagnara:
> Serge Knystautas wrote:
> > On 5/26/06, Stefano Bagnara <ap...@bago.org> wrote:
> >> Is what you propose a service like:
> >>
> >> public class RewritingService {
> >> public MailAddress[] rewrite(MailAddress address);
> >> }
> >
> > Just to throw it out there... one thing that makes sendmail rather
> > strong is that since it's aliases are quite structured, it can know
> > (and thus reject during SMTP protocol) recipients that it cannot
> > handle for authoritative domain. So perhaps add both a rewrite() and
> > a handles() method?
>
> Sendmail merges aliases, virtualusertable, users entries to fill in a
> single map for the matching.
>
> We can't do this because we have mailets.
>
> Let's say I have this mailet as my first mailet:
> <mailet match="SenderIsRegex=.*a.*5.*3@.*foo.*\.com" class="ToRepository">
> ..repository infos..
> </mailet>
>
> In the SMTPHandler we are not able to understand that the mailet will
> introduce some sort of whitelist for particular senders.
>
> If we want to provide full fastfailing to the SMTPHandler we ask the
> users to move much of their logic from Mailets processed by the
> SpoolManager to Handlers processed by the SMTPServer.
>
> I could also have mailets that allow only specific combinations of
> sender/recipients and so on.
>
> So we can support facilities for site administrators to manually insert
> "filters" in the SMTPhandler to fastfail, but we'll never automagically
> do that if we don't remove the Mailet support.
>
> A middle step would be the "in-handler" processor: add a processor that
> is executed after the data is closed (as a MessageHandler) that simply
> run a full Processor (defined in the handler configuration, with it's
> own spoolrepository) and if the message is GHOSTED consider it a
> succesfull delivery, if the message is sent to ERROR it can reply an
> SMTP error to the data.
>
> SMTP specifications says that a similar process should take a small
> amount of time (to avoid duplicate send).
>
> This would not give us fastfail at MAIL or RCPT commands but would give
> an administrator one more level of control.
>
> Stefan
Hmm, i don't think that do such tinks after the data is accepted is the
right way. I often hat issues with remote servers that did such thinks
and so my mailserver thought we lost the connection cause it get no
answer for long time on high load. The data should be accepted as fast /
soon as possible.
But i understand the problem we have with the current mailet and matcher
support. But anyway we should try to find a better fastfail support.
bye
Norman
Re: Virtual User Tables
Posted by Serge Knystautas <sk...@gmail.com>.
On 5/26/06, Stefano Bagnara <ap...@bago.org> wrote:
> Is what you propose a service like:
>
> public class RewritingService {
> public MailAddress[] rewrite(MailAddress address);
> }
Just to throw it out there... one thing that makes sendmail rather
strong is that since it's aliases are quite structured, it can know
(and thus reject during SMTP protocol) recipients that it cannot
handle for authoritative domain. So perhaps add both a rewrite() and
a handles() method?
--
Serge Knystautas
Lokitech >> software . strategy . design >> http://www.lokitech.com
p. 301.656.5501
e. sergek@lokitech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Virtual User Tables
Posted by Norman Maurer <nm...@byteaction.de>.
Am Freitag, den 26.05.2006, 09:42 +0200 schrieb Stefano Bagnara:
> Noel J. Bergman wrote:
> > Actually, the virtual user code is just about what it ought to be, although
> > what I proposed earlier would be a useful change. A few discussions that
> > haven't been implemented are largely because some people just don't
> > understand how SMTP and POP3 work. For example, the POP3 RFC says:
> >
> > USER name
> > Arguments:
> > a string identifying a mailbox (required), which is of
> > significance ONLY to the server
> >
> > It need *NOT* be the user's e-mail address. We could look at expanding the
> > range of possible mailbox identifiers, but there is no need.
>
> I agree: in fact we currently don't use the email address but tha name
> of the mailbox (often the localpart of the email address).
>
> I also think that we should at least support a "fullemail" accounts
> option. This would be without configuration and would allow to create
> users using the full email address and check their mail separately using
> "USER fullemail" via POP3. I would have lost much less hours replying to
> users of this list if we had a component or a configuration for this
> easy to understand, easy to implement scenario.
>
> But you know I don't like features themselves, I instead prefer to
> refactor the code and to expose services that allow us to modularize an
> aspect... [continue...]
>
> > This is not the problem with JAMES-426. The issue with JAMES-426 is that it
> > neither takes into account that we can have non-JDBC virtual tables, nor the
> > fact that we can have multiple virtual user tables. If implemented, it
> > would, at best, be a temporary solution for a sub-set of users.
> >
> > Exposing a virtual user mapping service, and then querying that service,
> > would resolve both issues.
> >
> > --- Noel
>
> About http://issues.apache.org/jira/browse/JAMES-426 I assigned it to
> me, and I explained that I don't like the proposed solution itself, and
> I started working on a modular way to implement it. My first comment
> explain the first part of the refactoring.
>
> Btw isLocalUser does not (and will never do) take in consideration the
> whole spooling and the possible AbstractVirtualUserTable,
> AbstractRedirect, AbstractNotify, ToRepository and any other mailet that
> allow to do something locally even with an email address not associated
> to a local user.
>
> This is in part related to the fastfailing for rcpts just proposed by
> Norman: Imho we can add that handler, but it should be optional, and
> should be carefully described that the handler is not aware of the full
> processing but of the only virtualuser table.
>
> Unfortunately you don't know if an email address is valid or not until
> you process the full processors/matchers/mailets.
> I agree we should modularize and move to top level service the most
> important mailet services (like the virtusertable you propose).
>
> Stefano
Sure the rcphandler should be optional. I could write an Handler which
check for existens and use the setBlockListed(true) and
setBlockListedDetail() for this needs. Emails on invalid recipients
increase the traffic and blacklists like spamcop often block servers
which accept email for not valid recipients and send bounces after that.
So if someone want to use this feature he must put this emailaddress
which is used on Matchers in the special table. But it should also be
possible to lookup for local recipients via isLocalEmail() method and
reject recipients which not valid after isLocalEmail() address is
checked and the special table.
Thats just my thoughts.
bye
Norman
RE: Virtual User Tables
Posted by "Noel J. Bergman" <no...@devtech.com>.
Stefano Bagnara wrote:
> Noel J. Bergman wrote:
> > That requires a bit of thought, rather than rushing into coding
> I have lost the count of discussions with no end, with no conclusions
> I'm sure I can find discussions about virtual users at least 3 years old
Actually, the virtual user code is just about what it ought to be, although
what I proposed earlier would be a useful change. A few discussions that
haven't been implemented are largely because some people just don't
understand how SMTP and POP3 work. For example, the POP3 RFC says:
USER name
Arguments:
a string identifying a mailbox (required), which is of
significance ONLY to the server
It need *NOT* be the user's e-mail address. We could look at expanding the
range of possible mailbox identifiers, but there is no need.
This is not the problem with JAMES-426. The issue with JAMES-426 is that it
neither takes into account that we can have non-JDBC virtual tables, nor the
fact that we can have multiple virtual user tables. If implemented, it
would, at best, be a temporary solution for a sub-set of users.
Exposing a virtual user mapping service, and then querying that service,
would resolve both issues.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Virtual User Tables
Posted by Stefano Bagnara <ap...@bago.org>.
Noel J. Bergman wrote:
> That requires a bit of thought, rather than rushing into coding
I'm against this fear of coding.
Writing code many times takes much less that discussing and it decreases
the misunderstandings because we all share the JVM/Java specification
knowledge.
I have lost the count of discussions with no end, with no conclusions,
or even discusssions with conclusions but with no one that ever
implemented them, or discussions with conclusions but that as soon as
you try to implement them you discover that you forgot to take a
specific issue into consideration.
I'm sure I can find discussions about virtual users at least 3 years old
in the James archives: I browse/search James archives at least 15
minutes per day (TO be added to the hours spent on the daily messages).
Btw I think the most important steps have been done:
http://issues.apache.org/jira/browse/JAMES-426
http://issues.apache.org/jira/browse/JAMES-508
Now we have the basis to introduce the feature.
If you search the archives I proposed this roadmap almost an year ago
but the discussion was never finished.
I prefer to receive vetoes or to revert something I already committed
than discussing full days and resulting in nothing done. At least in the
first case I have new code I like in my local james and if I am lucky
enough you like it too and when we finish the discussion "post code" we
already have the feature.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Virtual User Tables
Posted by "Noel J. Bergman" <no...@devtech.com>.
Norman commented:
> a modular virtual hosting support whould be a really nice thing.
> The current way the virtual user table support is not the best.
In what way? Actually, I would say that the current virtual user table code
is in pretty good shape, and is very powerful. The major thing that I would
do is factor out the virtual user table code to make it a service that can
be used by other components in the system. That way we can check to see if
I particular user would have a valid mapping, and if the mapping would be
local.
That requires a bit of thought, rather than rushing into coding, because we
can configure multiple virtual user tables, implying that any client of the
service would need to make sure that the desired mapping was being applied.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [jira] Commented: (JAMES-508) Make MailetContext.isLocalUser
domain aware
Posted by Norman Maurer <nm...@byteaction.de>.
Am Donnerstag, den 25.05.2006, 01:31 +0200 schrieb Stefano Bagnara:
> Noel J. Bergman (JIRA) wrote:
> > [ http://issues.apache.org/jira/browse/JAMES-508?page=comments#action_12413193 ]
> >
> > Noel J. Bergman commented on JAMES-508:
> > ---------------------------------------
> >
> > I don't have a problem with adding isLocalEmail to eventually replace isLocalUser, but we should keep isLocalServer, since there are some checks to just see if that domain is locally hosted.
>
> Sure!
> Now I changed the default isLocalUser to also check for "@" presence,
> and use @localhost if not present, then forwards the call to the new
> isLocalUser(MailAddress) that check both domain and user.
> isLocalServer("localhost") always return true.
>
> We already had the "localhost" hardcoded elsewhere, so I think I didn't
> add any issue with this.
>
> Upgrading current calls to isLocalUser to the full username we now are
> only a few steps to a modular virtual hosting support.
>
> Maybe I should change the new isLocalUser to isLocalEmail like you said.
>
> Stefano
Yeah isLocalEmail is a better name IMMO. Anyway a modular virtual
hosting support whould be a really nice thing. The current way the
virtual user table support is not the best.
bye
Norman
[jira] Commented: (JAMES-508) Make MailetContext.isLocalUser domain
aware
Posted by "Noel J. Bergman (JIRA)" <se...@james.apache.org>.
[ http://issues.apache.org/jira/browse/JAMES-508?page=comments#action_12413193 ]
Noel J. Bergman commented on JAMES-508:
---------------------------------------
I don't have a problem with adding isLocalEmail to eventually replace isLocalUser, but we should keep isLocalServer, since there are some checks to just see if that domain is locally hosted.
> Make MailetContext.isLocalUser domain aware
> -------------------------------------------
>
> Key: JAMES-508
> URL: http://issues.apache.org/jira/browse/JAMES-508
> Project: James
> Type: Improvement
> Components: James Core
> Reporter: Stefano Bagnara
> Assignee: Stefano Bagnara
> Fix For: 2.4.0
>
> Trying to resume an old task:
> 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.
> The proposed solution is:
> 1) change the isLocalUser documentation saying that you MUST provide the
> full email address
> 2) eventually allowing to use names without @ (the system will consider
> automatically @localhost)
> 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.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
[jira] Resolved: (JAMES-508) Make MailetContext.isLocalUser domain
aware
Posted by "Stefano Bagnara (JIRA)" <se...@james.apache.org>.
[ http://issues.apache.org/jira/browse/JAMES-508?page=all ]
Stefano Bagnara resolved JAMES-508:
-----------------------------------
Resolution: Fixed
> Make MailetContext.isLocalUser domain aware
> -------------------------------------------
>
> Key: JAMES-508
> URL: http://issues.apache.org/jira/browse/JAMES-508
> Project: James
> Type: Improvement
> Components: James Core
> Reporter: Stefano Bagnara
> Assignee: Stefano Bagnara
> Fix For: 2.4.0
>
> Trying to resume an old task:
> 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.
> The proposed solution is:
> 1) change the isLocalUser documentation saying that you MUST provide the
> full email address
> 2) eventually allowing to use names without @ (the system will consider
> automatically @localhost)
> 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.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org