I am not against this patch, actually this was one of the most important missing features for me. The current configuration is better in one (and only one) issue, it does provide feedback after about a day to the sender.
I have no idea about the implementation of DSN, but sending bounces to a processos with some mail attributes was a nice idea, I don't remember who wrote it. I would be happy if RemoteDelivery doesn't bounce back to the _from_ address, instead of the reverse path. If I have a few hours I will fix this. ----- Original Message ----- From: "Noel J. Bergman" <[EMAIL PROTECTED]> To: "James Developers List" <[EMAIL PROTECTED]> Sent: Wednesday, October 29, 2003 8:58 PM Subject: RE: [PATCH] RemoteDelivery multiple delay times > > I think it causes more trouble then benefit if it delays a mail for not > less > > then 5 days _without_ notifying the sender after 24 hours, saying that "I > am > > James, your email is delayed, but I am still trying to deliver". > > I understand your thought about DSN (something still pending to be done), > but how does the current state differ from what we'll have after merging > this change? As it currently stands, James will iterate for a certain > number of times, delaying 6 hours between. > > RemoteDelivery is an area with room for enhancement in many ways. DSN is > one of them. Do you have any ideas for how you would like the problem of > sending a DSN within the delivery process addressed? > > --- Noel > > > --------------------------------------------------------------------- > 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]
