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
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
