> "The *OTHER* of the *TWO* things I want to discuss is a > change to how the SMTP handler is structured. I want to > suggest a chained approach, although I'm not entirely sure of > which of a couple directions would be best.
Let me try to do an example use-case and understand your solution: Let's say we have a james configured with many processors and many matcher/mailets that provide specific aliasing/forwarding/virtusertable/localdelivery. If we want to add fast-fail per recipient then we need to create a tree of SMTPHandler plugins that provides functionalities similar to the mailet we used and add a configuration to the SMTPHandler to specify our processing. Am i correct? I really don't like the configuration replication but I think there is no chance to reuse current matcher/mailets and their configuration to produce a per recipient fast-fail. I still hope we can find a solution where we move configurations without replicate them. If we need to create an object chain (SMTP handler plugins) that given the currenct SMTP transaction status (sender IP, sender MAIL FROM, the last recipient RCPT TO) is able to run through virtusertables, aliasing, forwarding, local user table and provide a good reply (mailbox full, mailbox disabled, relay not allowed/mailbox not local, user unknown) (We can even supports the VRFY command this way), then why should't we use the same objects in a custom mailet running as the first mailet in the root processor? I mean: why should I configure the SMTP server to check my virtusertable and localusertable and then do it again in my spooler/processors? I don't like james to run twice the same code for each mail! Stefano --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
