The remote delivery code has some logic in it that determines whether it's a permanent or temporary delivery failure. I was actually working on this last night because certain temporary failures (such as the connect problems you're describing) are incorrectly getting classified as permanent. I'll send around a note once I've applied the patch. -- Serge Knystautas Loki Technologies - Unstoppable Websites http://www.lokitech.com/
Andrew Timberlake wrote: > I have one client who's SMTP server which is fairly busy, this results > in it being unavailable to collect mail at certain times. > > If I send a mail during a period where it is not accepting a connection, > I get a reply from James letting me know that it was unable to connect, > I would assume that based on the config snippet below that it would wait > and try again but this does not seem to be the case. > > I am using a version built from CVS about 2-3 days ago. > > Thanks for any help. > > <mailet match="All" class="RemoteDelivery"> > <outgoing> file://var/mail/outgoing/ </outgoing> > <!-- <outgoing> db://conf/mail-outgoing.properties </outgoing> --> > <!-- Number of milliseconds between delivery attempts --> > <delayTime> 21600000 </delayTime> > <!-- Number of failed attempts before returning to the sender --> > <maxRetries> 5 </maxRetries> > <!-- The number of threads that should be trying to deliver outgoing > messages --> > <deliveryThreads>5</deliveryThreads> > </mailet> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
