Thank you for your response and explaining how the Retries work. We went aggressive on the retries just to give the end users in our application a quicker turnaround times for non-delivery notification. Our application deals with extremely date-sensitive correspondence and deadlines. We just felt the 4 day standard was just too long to wait before a end user receives notification that their email they sent off was not delivered to the recipient. The email corresondence is crucial to make sure deadlines are not missed. The more aggressive 11 hour schedule gives the user time to make whatever corrections need to be made without missing those deadlines.
Thanks again. John Rose ASP Manager FoundationIP - Part of CPA Software Solutions Direct Dial: +1 612-236-9917 Email: [EMAIL PROTECTED] Fax: +1 612-332-0080 Computer Patent Annuities North America LLC / FoundationIP 900 Second Avenue South Suite 1700 Minneapolis, MN 55402 CPA is the world's leading provider of outsourced IP services, For further information about our products and services go to www.cpaglobal.com. Stefano Bagnara <[EMAIL PROTECTED]> 03/23/2007 04:49 AM Please respond to "James Users List" <[email protected]> To James Users List <[email protected]> cc Subject Re: question on remotedelivery retries Here is the attempts list using your config: 1: minute 0m 2: minute 5m (5 minutes) 3: minute 15m (10 minutes) 4: minute 30m (15 minutes) 5: minute 50m (20 minutes) 6: minute 1h15m (25 minutes) 7: minute 1h45m (30 minutes) 8: minute 2h15m (30 minutes) 9: minute 2h45m (30 minutes) 10: minute 3h15m (30 minutes) 11: minute 3h45m (25 minutes) 12: minute 4h15m (30 minutes) 13: minute 4h45m (30 minutes) 14: minute 5h15m (30 minutes) 15: minute 5h45m (30 minutes) 16: minute 6h15m (25 minutes) 17: minute 6h45m (30 minutes) 18: minute 7h15m (30 minutes) 19: minute 7h45m (30 minutes) 20: minute 8h15m (30 minutes) 21: minute 8h45m (25 minutes) 22: minute 9h15m (30 minutes) 23: minute 9h45m (30 minutes) 24: minute 10h15m (30 minutes) 25: minute 10h45m (30 minutes) So after 10 hours and 45 minutes (+ possible delayes due to processing time and workload delay) soft failures are bounced back as permanent. The issue of wrong domain to result in soft failures has been discussed. Some committer thinks that this is a bug, someone else say that this is the behaviour intended by the RFC (I'm in the fist category). The result is that current trunk code has a workaround to allow configurability for this special issue, but 2.2 and 2.3 leave you with this "problem" (someone else would say "feature"). Please note that your delayTime configuration is a bit aggressive by specs. RFC suggests to retry for at least 4 days (if I remember correctly) instead you try only for 11 hours. I understand why you decreased so much the retries (but then you can also reduce the total number of attempts that are only wasting resources) but I wanted to warn you about the problem with short retry times. Stefano John Rose ha scritto: > We are using James 2.2 as a means of receiving and sending email in our > Java application. I have a question on the amount of time for retries on > non-delivered emails. Our configuration is as follows: > > <!-- using delay time to retry delivery and the maximum number of retries > --> > <mailet match="All" class="RemoteDelivery"> > <outgoing> file://var/mail/outgoing/ > </outgoing> > <!-- alternative database repository > example below --> > <!-- > <outgoing> db://maildb/spool/outgoing </outgoing> > --> > <!-- Delivery Schedule based upon RFC > 2821, 4.5.4.1 --> > <!-- 5 day retry period, with 4 attempts > in the first > hour, two more within the first 6 hours, and then > every 6 hours for the rest of the period. --> > <delayTime> 5 minutes </delayTime> > <delayTime> 10 minutes </delayTime> > <delayTime> 15 minutes </delayTime> > <delayTime> 20 minutes </delayTime> > <delayTime> 25 minutes </delayTime> > <delayTime> 30 minutes </delayTime> > <maxRetries> 25 </maxRetries> > > We are getting complaints from our end users that when sending an email > with an invalid domain the bounceback message is taking over 11 hours to > be returned back to them. I can't quite reconcile that with the setup > above. How do the times work above and what should be be changing to > reduce the lag time - the number of maxretries or the individual > delaytimes. > > Thank you. > > John Rose > ASP Manager > > FoundationIP - Part of CPA Software Solutions > > Direct Dial: +1 612-236-9917 > Email: [EMAIL PROTECTED] > Fax: +1 612-332-0080 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] ******************************************************************************** The information in this message is confidential and may be legally privileged. It is intended solely for the addressee; access to this email by anyone else is unauthorized. If you are not the intended recipient: (1) you are kindly requested to return a copy of this message to the sender indicating that you have received it in error, and to destroy the received copy; and (2) any disclosure or distribution of this message, as well as any action taken or omitted to be taken in reliance on its content, is prohibited and may be unlawful. ********************************************************************************
