Stefano,
I am still working on 2 and 3. I thought I could release one patch with the
following changes
1. UnknownCommandHandler.java
a) Added
//If there was message failure, don't consider it as an unknown command
if (state.get(MESG_FAILED) != null) {
return;
}
b) Modified the message format to
500 5.5.1 Command <commandName> unrecognized.
2. Since the Handlers cannot store state internally. The SMTPSession exposes
Message scope and session scope hashmaps to store state information.
The Message Scope HashMap will be cleared when the message sent or
aborted
The Session Scope HashMap will be cleared after the session ends
--Anagha
On 8/25/05, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
> > > If you like any of this ideas I can help you identifying james
> > > services you need and how to use Avalon lifecycle
> > interfaces to gain
> > > access to the user db or to the repositories.
> >
> > I like all of them. To begin with I will work on these
> > 1.
> > MAILHandler that allow to specify banned from addresses.
>
> You don't need interfaces for this, just local configurations.
> You can look at the SenderIsRegex.java code that should be similar.
>
> > 2. RCPTHandler that check the user inbox quota and reply an
> > error when overquota.
>
> AbstractStorageQuota.java does similar things.
> You probably need to lookup UsersStore and MailServer roles.
> You can do this by adding the Serviceable interface to the involved handler
> and adding ContainerUtil code to propagate the services in the
> handlerchain.
> Smtpserver already have the 2 services described (UsersStore and
> MailServer).
> You already do "ContainerUtil.configure(handler,children[i]);" in the
> SMTPhandlerChain. You just need to add ContainerUtil.service,
> ContainerUtil.initialize or any other needed lifecycle method.
>
> > 3. A ConnectHandler that would check how many messages are in
> > the main spool and reply a "too busy, retry later" code
> > instead of accepting the connection.
>
> This is more difficult by now, I'm not sure it's even feasible by now.
>
> Currently the smtpserver does not have links to the main spool.
> You can do this but it will be harder:
>
> Change the SMTPServer.xinfo adding the spool dependency:
> <dependency>
> <service name="org.apache.james.services.SpoolRepository" version="1.0"/>
> </dependency>
>
> Change the james-assembly.xml filling the dependecy in the <block
> name="smtpserver" .. /> block.
> This is the line to add dependency on the main spoolrepository.
> <provide name="spoolrepository"
> role="org.apache.james.services.SpoolRepository"/>
>
> After that you can do the service lookup in the SMTPServer.service method
> adding the:
> spoolrepository = (SpoolRepository)
> manager.lookup("org.apache.james.services.SpoolRepository");
>
> The main problem now is that the spoolrepository does not provide
> statistics
> about its content and we cannot retrieve the full queue to count the items
> because it would be a performance bottleneck!
> Reminder: We probably should add statistics to the next version of
> MailRepository/SpoolRepository APIs.
>
> > Help me with the interfaces I need to know to implement the above.
> >
> > --anagha
>
> 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]
