Yeah, I like that idea of a bounce processor for the RemoteDelivery. So the thing is, the LocalDelivery mailet DOESN'T handle a bounce condition. The process that calles LocalDelivery is supposed to check that this is a valid mailbox before calling LocalDelivery to store it... the code you are looking at in LocalDelivery (that's sending it to the error processor) should only get used if the mail repository is corrupt or there's some other configuration error. You use a matcher before calling LocalDelivery so that you can then handle delivering to default mailboxes or a custom bounce or what-have-you.
RemoteDelivery also has a few states and additional info because it will contain who it was trying to connect to and the error messages. RemoteDelivery also has retries in certain cases, you actually have a variety of "bounce"-esque conditions... I've seen some servers give a warning notice when a message doesn't deliver immediately and gets put in the try-again-later bucket. Anyway, just some thoughts... please feel free to improve on it however you think best. I'm still too busy besides lurking and moderating. :( -- Serge Knystautas Loki Technologies - Unstoppable Websites http://www.lokitech.com Danny Angus wrote: > worthwhile, yes. > > Although the mailet API has bounce() in the mailet context I'm pretty sure > that creating a bounce processor which would allow people to configure > bounces would be worthwhile. I think you'd have to alter all the bounce() > methods to send their mail to the bounce processor though. > > > >>-----Original Message----- >>From: Noel J. Bergman [mailto:[EMAIL PROTECTED]] >>Sent: 06 September 2002 15:46 >>To: James Developers List >>Subject: RE: Local vs Remote delivery failures >> >> >> >>>>Why isn't the handling consistent? >>> >>>probably because this is an Open Source project, and any number of >> >>different >> >>>people have any number of different ideas. >> >>That was my first thought, but checking the code and CVS first, >>it appeared >>to come from the same origin. So I thought that there might be >>some deeper >>reason for why it was handled two different ways; a reason I had missed. >> >>Similarly with my question about instrumenting LocalDelivery and >>RemoteDelivery to accept a processor name for failure notification. I >>wasn't making the assumption that it hadn't been considered in the past. >>Instead I was asking. >> >>Should I take your responses to mean that you don't know of any >>reasons for >>the difference, and that you believe it might be worthwhile (post-2.1?) to >>make such a change? >> >> --- Noel -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
