You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by Soeren Hilmer <so...@tietoenator.com> on 2003/10/29 16:17:26 UTC
[PATCH] RemoteDelivery multiple delay times
Changes from previous patch:
i) All accept methods in SpoolRepository and implementing classes now returns
a Mail instance instead of the key (should that have been MailImpl instances
?)
ii) JamesSpoolManager changed as it calls one of the accept method mentioned
above.
iii) For performance reasons (not needing to make an Iterator instance for
each resend) the parsed Delay objects are expanded into an array.
iv) Regex is now done the correct way.
v) patch is against branch_2_1_fcs
--S�ren
--
S�ren Hilmer, M.Sc.
R&D manager Phone: +45 70 27 64 00
TietoEnator IT+ A/S Fax: +45 70 27 64 40
Ved Lunden 12 Direct: +45 87 46 64 57
DK-8230 �byh�j Email: soren.hilmer@tietoenator.com
Re: [PATCH] RemoteDelivery multiple delay times
Posted by Soeren Hilmer <so...@tietoenator.com>.
I was thinking about doing a parameter for RemoteDelivery like:
<failureNoticeAtAttempt> 4 </failureNoticeAtAttempt>
Which would indicate that the failure notice was to be sendt out after attempt
4.
As the notice text should then include something like "trying for x more days"
the notice would have to be configurable as well, which is also high on what
I am planning to submit a patch for, mainly because I live in a country where
english is not the main language, so people get a little confused about the
"Hi. This is the James mail server at " stuff.
BTW, Thanks for the nomination Noel.
--Søren
On Wednesday 29 October 2003 21:47, Hontvari Jozsef wrote:
> (on bounces I also mean failed attempts, before the configured retry
> attemps ended, this event could be used for such a notification)
>
>
> ----- Original Message -----
> From: "Hontvari Jozsef" <ho...@solware.com>
> To: "James Developers List" <se...@james.apache.org>
> Sent: Wednesday, October 29, 2003 9:43 PM
> 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.
> >
> > 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" <no...@devtech.com>
> > To: "James Developers List" <se...@james.apache.org>
> > 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: server-dev-unsubscribe@james.apache.org
> > > For additional commands, e-mail: server-dev-help@james.apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> > For additional commands, e-mail: server-dev-help@james.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
--
Søren Hilmer, M.Sc.
R&D manager Phone: +45 70 27 64 00
TietoEnator IT+ A/S Fax: +45 70 27 64 40
Ved Lunden 12 Direct: +45 87 46 64 57
DK-8230 Åbyhøj Email: soren.hilmer@tietoenator.com
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: [PATCH] RemoteDelivery multiple delay times
Posted by Vincenzo Gianferrari Pini <vi...@praxis.it>.
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:noel@devtech.com]
> 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: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [PATCH] RemoteDelivery multiple delay times
Posted by Mark Daring <co...@chello.at>.
----- Original Message -----
From: "Andreas Göggerle" <an...@pansoft.de>
To: "'James Developers List'" <se...@james.apache.org>
Cc: <we...@pansoft.de>
Sent: Friday, November 07, 2003 2:27 PM
Subject: RE: [PATCH] RemoteDelivery multiple delay times
> But why do I need to extend the MimeMessage class? As far as I can see,
> it does nothing new.
That's because of getting rid off all the unwanted default-headers
MimeMessage generates in writeTo(...). Use your original MimeMessage instead
you will see what i mean. You will also get an error message.
But keep in mind with this writeTo version no auto-encoding is done, so you
are responsible for RFC-compliance. As for that matter take a look at
MimeUtiltity.encode(...). This is only necessary when you have non ascii
characters in your text like "Umlaute".
If you dont know your encoding scheme use
MimeUtility.getEncoding(DataHandler dh).
M
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: [PATCH] RemoteDelivery multiple delay times
Posted by Andreas Göggerle <an...@pansoft.de>.
Mark Daring wrote:
> you dont need to write your own DataHandler, just use what
> allready exists.
> You could use the default Handler of the
> message/rfc822-messages and extend
> the MimeMessage class.
> For example your mailcap-file (take a look at
> mail.jar/META-INF/mailcap)
> would then look something like this:
> "...
> message/rfc822;;
> x-java-content-handler=com.sun.mail.handlers.message_rfc822
> message/delivery-status;;
> x-java-content-handler=com.sun.mail.handlers.message_rfc822"
I'll test this as soon as I get a little time for it.
But why do I need to extend the MimeMessage class? As far as I can see,
it does nothing new.
Thanks for your help!
Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [PATCH] RemoteDelivery multiple delay times
Posted by Mark Daring <co...@chello.at>.
----- Original Message -----
From: "Andreas Göggerle" <an...@pansoft.de>
To: "'James Developers List'" <se...@james.apache.org>
Cc: <we...@pansoft.de>
Sent: Thursday, October 30, 2003 3:30 PM
Subject: RE: [PATCH] RemoteDelivery multiple delay times
> But i still have one (minor?) problem with my Mailet to be RFC conform:
> JavaMail 1.3.1 doesn't support the MIME-Type "message/delivery-status" and
I
> don't have the time to look at the JavaBeans Activation Framework for
> writing an own DataContentHandler for this MIME-Type. At the monent I send
> the delivery-report as MIME-Type "text/plain". If someone is willing to do
> the DataContentHandler or if you want to accept it even if it's not 100%
RFC
> conform I can contribute the current Mailet.
>
> Andreas
Servus Andreas,
you dont need to write your own DataHandler, just use what allready exists.
You could use the default Handler of the message/rfc822-messages and extend
the MimeMessage class.
For example your mailcap-file (take a look at mail.jar/META-INF/mailcap)
would then look something like this:
"...
message/rfc822;; x-java-content-handler=com.sun.mail.handlers.message_rfc822
message/delivery-status;;
x-java-content-handler=com.sun.mail.handlers.message_rfc822"
and your own MimeMessage class maybe like this:
"...
public class DSNMessage extends MimeMessage {
private String type = "";
public DSNMessage() {
super(Session.getDefaultInstance(System.getProperties(), null));
}
public void setContent(Object o, String type) throws MessagingException {
this.type = type;
super.content = (byte[])o;
}
public void writeContentTo(OutputStream outs)
throws java.io.IOException, MessagingException {
outs.write(super.content);
outs.flush();
}
public void writeTo(OutputStream outs, String as[])
throws IOException, MessagingException
{
outs.write(super.content);
outs.flush();
}
}".
If you want to test it, here is a suggestion:
"...
private void test() {
try {
MimeMultipart mp = new MimeMultipart();
MimeBodyPart body1 = new MimeBodyPart();
body1.setContent("Plain TEXT","text/plain");
mp.addBodyPart(body1);
Session session = Session.getDefaultInstance(System.getProperties());
MimeBodyPart body2 = new MimeBodyPart();
Message m = new DSNMessage();
m.setContent(new
String("DSN-MESSAGE").getBytes(),"message/delivery-status");
body2.setContent(m,"message/delivery-status");
mp.addBodyPart(body2);
// Andreas if you want to support type text/rfc822-headers you would
definetly repeat the steps above
MimeBodyPart body3 = new MimeBodyPart();
body3.setContent("RFC822-HEADER","text/rfc822-headers");
mp.addBodyPart(body3);
Message msg = new MimeMessage(session);
ContentType cType = new ContentType();
cType.setPrimaryType("multipart");
cType.setSubType("report");
cType.setParameter("report-type", "delivery-status");
String contentType = cType.toString();
msg.setContent(mp,contentType);
msg.saveChanges();
msg.writeTo(System.out);
}
"
Hope this helps.
M
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
DSNBounce Mailet (was [PATCH] RemoteDelivery multiple delay times)
Posted by "Noel J. Bergman" <no...@devtech.com>.
Andreas,
> I wrote a DSNBounce Mailet (extending Vincenzos AbstractNotify)
> that produces Delivery Status Notifications using the format
> described in RFC 3462 - RFC 3464.
Excellent. It would be very good to have a DSN Mailet submitted. :-) Feel
free to submit patches for the other parts as well.
> Therefor I replaced the call of "bounce(mail, ex);" at the end of
> RemoteDeliverys failMessage() by the following:
> mail.setAttribute("DSN-error", ex);
> mail.setState("dsn");
> MailetContext mc = getMailetContext();
> try {
> mc.sendMail(mail);
> } catch (MessagingException e) {
> log("Exception re-inserting failed mail: ", e);
> }
> //bounce(mail, ex);
I think it would be a good idea to allow the DSN processor to be
parameterized, and if there isn't one, use the default handling (for now).
And it would be a good idea to wrap the DSN code into a convenient method
for other pieces of code to use as necessary, rather than replicate it.
MailImpl has a bounce method that is supposed to return a Mail object
containing the bounce notice. I don't believe, off-hand, that it is used,
nor am I sure if it continues to have any value. MailetContext has bounce
methods that are intended to send the notice. It might be useful to modify
them such that we can provide the necessary information, such as the
message, the DSN-status, any exception, and the target DSN processor. The
MailetContext can verify that the processor exists, which would be a good
thing.
> My DSNBounce Mailet could easy be re-written to handle all DSNs, not only
> Bounces like it does at the moment. "delayed"-reports and
"success"-reports
> may be done in this way. But therefore more information must be provided
to
> the Mailet. I would suggest a DSN-specific Attribute that holds an
"Enhanced
> Mail System Status Code" (RFC3463). This should be set either by the
> SMTP-handler (which could implement RFC3461 - SMTP service extension for
> DSN) or by RemoteDelivery. At the moment my Mailet is "guessing" this
Status
> Code using the exception catched in RemoteDelivery.
I agree. However, I think that we also need to parameterize the system so
that we can be selective about which DSNs we want to provide. Not everyone
will want to provide as much information.
> JavaMail 1.3.1 doesn't support the MIME-Type "message/delivery-status"
> and I don't have the time to look at the JavaBeans Activation Framework
> for writing an own DataContentHandler for this MIME-Type.
For now, use text/plain. Far better than nothing, and we can improve it
incrementally.
Thoughts?
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: [PATCH] RemoteDelivery multiple delay times
Posted by Andreas Göggerle <an...@pansoft.de>.
Hi,
I wrote a DSNBounce Mailet (extending Vincenzos AbstractNotify) that
produces Delivery Status Notifications using the format described in RFC
3462 - RFC 3464.
This Mailet gets the failed Message with the Exception that occured attached
as Attribute.
Therefor I replaced the call of "bounce(mail, ex);" at the end of
RemoteDeliverys failMessage() by the following:
// setting attributes for DSN mailet
mail.setAttribute("DSN-error", ex);
mail.setState("dsn");
// re-insert the mail into the spool for getting it passed to the
DSN-processor
MailetContext mc = getMailetContext();
try {
mc.sendMail(mail);
} catch (MessagingException e) {
// we shouldn't get an exception, because the mail was already processed
log("Exception re-inserting failed mail: ", e);
}
// bounce() is no longer needed
//bounce(mail, ex);
so the failed message isn't bounced, but goes to a DSN processor, where the
DSNBounce Mailet does the Bounce and ghosts the original Mail.
in my config.xml I defined a processor "dsn" like this:
<!-- the DSN processor -->
<processor name="dsn">
<!-- all mails go to the DNSBounce Mailet -->
<mailet match="All" class="DSNBounce">
<!-- The sender defaults to the postmaster address -->
<sender> Mailserver@picard.intern.pansoft.de </sender>
<!-- Subject prefix, defaults to "Re:" -->
<prefix> ERROR: </prefix>
<!-- attachment: how should the original mail be attached? -->
<!-- MESSAGE or NONE, defaults to MESSAGE -->
<attachment> MESSAGE </attachment>
<!-- passThrough, defaults to false -->
<passThrough> false </passThrough>
<!-- debug, default = false -->
<debug> false </debug>
</mailet>
</processor>
My DSNBounce Mailet could easy be re-written to handle all DSNs, not only
Bounces like it does at the moment. "delayed"-reports and "success"-reports
may be done in this way. But therefor more information must be providet to
the Mailet. I would suggest a DSN-specific Attribute that holds an "Enhanced
Mail System Status Code" (RFC3463). This should be set either by the
SMTP-handler (which could implement RFC3461 - SMTP service extension for
DSN) or by RemoteDelivery. At the moment my Mailet is "guessing" this Status
Code using the exception catched in RemoteDelivery.
But i still have one (minor?) problem with my Mailet to be RFC conform:
JavaMail 1.3.1 doesn't support the MIME-Type "message/delivery-status" and I
don't have the time to look at the JavaBeans Activation Framework for
writing an own DataContentHandler for this MIME-Type. At the monent I send
the delivery-report as MIME-Type "text/plain". If someone is willing to do
the DataContentHandler or if you want to accept it even if it's not 100% RFC
conform I can contribute the current Mailet.
Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: [PATCH] RemoteDelivery multiple delay times
Posted by "Noel J. Bergman" <no...@devtech.com>.
> 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: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [PATCH] RemoteDelivery multiple delay times
Posted by Hontvari Jozsef <ho...@solware.com>.
(on bounces I also mean failed attempts, before the configured retry attemps
ended, this event could be used for such a notification)
----- Original Message -----
From: "Hontvari Jozsef" <ho...@solware.com>
To: "James Developers List" <se...@james.apache.org>
Sent: Wednesday, October 29, 2003 9:43 PM
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.
>
> 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" <no...@devtech.com>
> To: "James Developers List" <se...@james.apache.org>
> 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: server-dev-unsubscribe@james.apache.org
> > For additional commands, e-mail: server-dev-help@james.apache.org
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [PATCH] RemoteDelivery multiple delay times
Posted by Hontvari Jozsef <ho...@solware.com>.
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" <no...@devtech.com>
To: "James Developers List" <se...@james.apache.org>
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: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: [PATCH] RemoteDelivery multiple delay times
Posted by "Noel J. Bergman" <no...@devtech.com>.
> 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: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [PATCH] RemoteDelivery multiple delay times
Posted by Hontvari Jozsef <ho...@solware.com>.
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".
----- Original Message -----
From: "Noel J. Bergman" <no...@devtech.com>
To: "James Developers List" <se...@james.apache.org>;
<so...@tietoenator.com>
Sent: Wednesday, October 29, 2003 5:34 PM
Subject: RE: [PATCH] RemoteDelivery multiple delay times
> If no one else gets to this sooner, I should have some time to review it
on
> the weekend. One minor thing that I'm not spotting, which I can add when
I
> integrate it, is a change to james-config.xml to use this in new
> deployments.
>
> My proposed default configuration is:
>
> <delayTime> 5 minutes </delayTime>
> <delayTime> 10 minutes </delayTime>
> <delayTime> 45 minutes </delayTime>
> <delayTime> 2 hours </delayTime>
> <delayTime> 3 hours </delayTime>
> <delayTime> 6 hours </delayTime>
>
> <maxRetries> 25 </maxRetries>
>
> As I mentioned once before, that provides a 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.
>
> Any comments, alternatives, etc.?
>
> --- Noel
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: [PATCH] RemoteDelivery multiple delay times
Posted by "Noel J. Bergman" <no...@devtech.com>.
If no one else gets to this sooner, I should have some time to review it on
the weekend. One minor thing that I'm not spotting, which I can add when I
integrate it, is a change to james-config.xml to use this in new
deployments.
My proposed default configuration is:
<delayTime> 5 minutes </delayTime>
<delayTime> 10 minutes </delayTime>
<delayTime> 45 minutes </delayTime>
<delayTime> 2 hours </delayTime>
<delayTime> 3 hours </delayTime>
<delayTime> 6 hours </delayTime>
<maxRetries> 25 </maxRetries>
As I mentioned once before, that provides a 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.
Any comments, alternatives, etc.?
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org