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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
