Re: [courier-users] courier tmp directory

[Honza M. <ma...@de...>]

Sam Varshavchik wrote:
> 
> On Fri, 1 Sep 2000, Jan Mach wrote:
> 
> > > Normally there's an attempt to clean things up, if a message delivery is
> > > aborted.  Files shouldn't be left in tmp except when there's a major
> > > crash.
> > >
> > >If you're crashing due to large messages, set an upper limit on allowed
> > >message size.
> >
> > Problem is it was only one message but I can't be delivered for some reason
> > (may be connection is interrupted).
> >
> > And this message was stored in that tmp directory moretimes. Result was it
> > took a lot of disk space.
> 
> If one message is sufficient to run out of disk space, this means that
> your system is incorrectly configured.
> 
> > I don't know how to avoid this situation. Any advice, please ?
> 
> Set the maximum size of messages to some reasonable value.  See
> "sizelimit" in courier(8) man page.
> 

Ok, I can set size limit for incomming messages. 
But my problem is that there is one may be broken message. It can't be
delivered whole.
For other messages it works fine (courier stores it in tmp directory and
then deliver
to right user).

Another true is that that message is stored on secondary mail server
which is trying to deliver it.
But don't know why but it can't deliver it whole. May be there is
interrupted connection.
So secondary mail server tryes to deliver it again and again and so.

I have some solutions:

1) restrict size limit - problem is that incomming message should fit
this limit but can be 
delivered for ever (or for some days let's say 5 days) and in case there
is broken connection
then same sitioation occures.

2) somehow disable acceptig connection from that server (problem is that
is our secondary mail server
and I don't think so I can disable it).

3) somehow tell courier (better say submit) that it can delete broken
messages in let's say 5 hours.

Any advice (for broken messages - isn't complete so it can't be
delivered and have to stay in tmp directory I know).

Thanks.

Regards,

Jan Mach