[prev in list] [next in list] [prev in thread] [next in thread]
List: james-user
Subject: Re: question on remotedelivery retries
From: John Rose <JRose () foundationip ! com>
Date: 2007-03-23 16:59:08
Message-ID: OF9A4A5B2B.A5DA74C5-ON862572A7.005CB666-862572A7.005D75E2 () cpaintellevate ! com
[Download RAW message or body]
--=_alternative 005D75E0862572A7_=
Content-Type: text/plain; charset="US-ASCII"
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: jrose@foundationip.com
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 <apache@bago.org>
03/23/2007 04:49 AM
Please respond to
"James Users List" <server-user@james.apache.org>
To
James Users List <server-user@james.apache.org>
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: jrose@foundationip.com
> Fax: +1 612-332-0080
---------------------------------------------------------------------
To unsubscribe, e-mail: server-user-unsubscribe@james.apache.org
For additional commands, e-mail: server-user-help@james.apache.org
********************************************************************************
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.
********************************************************************************
--=_alternative 005D75E0862572A7_=--
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic