This has always been a problem for my production system, whose senders are employees of my company. I had to make a choice, so I set <delayTime> 1800000 </delayTime> and <maxRetries> 8 </maxRetries>, to have the sender informed of a failure within 8x30 minutes = 4 hours = half of a working day.
The problem is that there are three categories of errors causing failures: (i) a bad username with a good domain name, (ii) a bad domain name and (iii) problems sending to a good domain name. The sender is almost immediately notified with a bounce in case (i), or at least timing is outside of James control; in case (ii) the sender should be notified as soon as possible, so delayTime * maxRetries should be small; in case (iii) there should be enough time to allow the network or the recipient server to come up again if it was down, so delayTime * maxRetries should be high. As said, I had to bias towards case (ii), with a (for me) reasonable compromise. So Noel's suggestion would be great. I'm sorry of asking features while in the meantime not having been able to contribute in the last weeks, but I've been very busy. From the next week I think I'll be back, at least partially :-). Vincenzo > -----Original Message----- > From: Noel J. Bergman [mailto:[EMAIL PROTECTED] > Sent: mercoled� 29 ottobre 2003 22.10 > To: James Developers List > Subject: RE: [PATCH] RemoteDelivery multiple delay times > > > > 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. > > Actually, the "feedback" is when it fails. If you want total failure, you > can use a configuration that matches the current one. But it isn't really > RFC compliant, since the RFC really suggests a longer period. > > What we could do is modify the failMessage method to send notices > related to > temporary failures, rather than just permanent ones. That might > be feasible > now, with some of the other changes that have been made to RemoteDelivery. > > > 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. > > DSN == Delivery Status Notification. There is an RFC for it. > > --- 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]
