james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vincenzo Gianferrari Pini" <vincenzo.gianferrarip...@praxis.it>
Subject RE: [PATCH] RemoteDelivery multiple delay times
Date Thu, 30 Oct 2003 08:20:32 GMT
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


Mime
View raw message