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]
