> Make sure that you fully solve the processor name thing
> though, you don't want to have to deal with James users when
> SPAM's and ERROR's get handled in the wrong place, and
> toProcessor _appears_ not to work.
When a sendMail is done (even with the state option) the mail enter in the
main spoolmanager and I think I can't/shouldn't do anything to avoid this.
About the error and other processor I think that they should be handled like
this:
<dedicatedspoolmanager>
<processor name="error">
<mailet match="All" class="ToSpoolRepository">
<repositoryPath>db://maildb/spool/dedicatedspool</repositoryPath>
<processor> error </processor>
</mailet>
</processor>
</dedicatedspoolmanager>
Note that the <processor> tag is supreflous because we already have a
message in the "error" state.
Is there a way to get a spoolmanager name so I can add a named path to the
ToSpoolRepository like this?:
<mailet match="All" class="ToSpoolRepository">
<spoolManager> dedicatedspoolmanager </spoolManager>
<processor> error </processor>
</mailet>
I see that currently the "error" processor is handled differently in
different classes. Some mailet simply set a new state and does a
spool.store(mail) while other mailets (LocalDelivery) do
"getMailetContext().sendMail(mail.getSender(), errors, message,
Mail.ERROR);" or simply (as RemoteDelivery->bounceProcessor does)
mail.setState(Mail.ERROR); getMailetContext().sendMail(mail)
RemoteDelivery->bounceProcessor configuration simply does a setState and
sendMail: this would be weird when the remoteDelivery is configured in a
secondary spoolmanager.
How do you think we should handle this?
I think that sendMail with a status should not be available to mailets and
that a mail that goes through sendMail should always enter from the root
processor of the main repository.
LocalDelivery and RemoteDelivery use the sendMail in Mail.Error processor
because they have no ability to simply notify an error but I think that we
should implement a sendDeliveryStatusNotification(Mail) to the
MailetContext. I need a similar behaviour in the MailetContext API for
ESMTP-DSN too.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
