Details
-
Bug
-
Status: Closed
-
Critical
-
Resolution: Fixed
-
2.3.0, 3.0.0
-
None
Description
Bernd submitted this to the list:
I discovered a potential issue today. I could not yet do an in-depth analysis of the problem, but maybe someone can reproduce.
I set up vanilla james config and in the users-store section replaced the default db-store with file.
After that I get the following errors every time I send a mail to an internal user account (and the mail is not received):
19/05/06 17:50:21 INFO James.Mailet: RemoteDelivery: Attempting delivery of Mail1148053815529-51 to host localhost at 127.0.0.1 for addresses [test_ext2@mail.sample.com]
19/05/06 17:50:21 INFO James.Mailet: Error while storing mail.
java.lang.ClassCastException
at org.apache.james.transport.mailets.UsersRepositoryAliasingForwarding.processMail(UsersRepositoryAliasingForwarding.java:193)
at org.apache.james.transport.mailets.UsersRepositoryAliasingForwarding.service(UsersRepositoryAliasingForwarding.java:107)
at org.apache.james.transport.mailets.LocalDelivery.service(LocalDelivery.java:62)
at org.apache.james.transport.LinearProcessor.service(LinearProcessor.java:421)
at org.apache.james.transport.JamesSpoolManager.process(JamesSpoolManager.java:400)
at org.apache.james.transport.JamesSpoolManager.run(JamesSpoolManager.java:306)
at java.lang.Thread.run(Thread.java:534)
19/05/06 17:50:21 INFO James.Mailet: RemoteDelivery: Mail (Mail1148053815529-51) sent successfully to localhost at 127.0.0.1 for [test_ext2@mail.sample.com]
19/05/06 17:50:21 INFO James.Mailet: ToRepository: Storing mail Mail1148053821629-56 in file://var/mail/error
And here is an analysis of the problem:
As far as I know aliasing and forwarding is available only when the user is a JamesUser.
The "UsersRepositoryAliasingForwarding" mailet is a mailet that compose the "old" LocalDelivery mailet. I introduced it during a refactoring a few months ago.
1) We should add a check: if the user is not a JamesUser we simply skip the aliasing/forwarding block, so we avoid the ClassCast.
But the problem is not so easy, and is not really there. The problem is probably in a refactoring I did 2 months ago to avoid the use of deprecated methods.
Before my refactoring, when adding users using RemoteManager the remoteManager called the MailServer.addUser method if you were on the localusers, otherwise it create new DefaultUser. the James.addUser was instead creating a DefaultJamesUser by default.
In fact this is not so correct: the best way would be to invoke the usersRepository.addUser method directly without using the DefaultUser object from RemoteManager.
This is easy but is not a solution again.
The UsersFileRepository.addUser(username, password) method, creates DefaultUsers and not DefaultJamesUsers by default.
One of the refactoring I planned for 2.4 was the UsersRepository/Authentication one, so this will be fixed for 2.4 anyway, but we should also decide what to do for 2.3.
I would do at least:
a. Add a check to UsersRepositoryAliasingForwarding to skip non JamesUsers (easy bugfix)
b. Change the remotemanager to user the usersRepository.addUser(username, password) instead of creating a DefaultUser and use the usersRepository.addUser(user).
Then we have further options:
c1. do nothing else: we work differently from james 2.2 because newly created users for FileUsersRepository will not support aliasing/forwarding.
c2. we can change the FileUsersRepository.addUser method to create DefaultJamesUsers by default
c3. we can add a FileJamesUsersRepository identical to the FileUsersRepository but creating DefaultJamesUsers by default and put either put it as default in the config.xml or as an option.
My preference is for c2 or for c3 (adding it as the default).