Re: [Exim] More on exim and cyrus mailbox quotas

Kezdőlap
Üzenet törlése
Válasz az üzenetre
Szerző: Exim Users Mailing List
Dátum:  
Címzett: exim-users
Tárgy: Re: [Exim] More on exim and cyrus mailbox quotas
[ On Thursday, August 12, 1999 at 19:42:02 (+0200), F.F. Jacot-Guillarmod wrote: ]
> Subject: [Exim] More on exim and cyrus mailbox quotas
>
> But there's two problems I've encountered in checking that cyrus
> quotas handshake correctly with exim and requeue mail destined for an
> overquota mailbox. Cyrus signals correctly with a "75" temporary error,
> but exim bounces the mail immediately instead of holding it in the
> queue. As far as I can see, the transport is set up to do just this,
> but no way...


I think you might mis-understand the meaning of EX_TEMPFAIL. In the
description is says "user is invited to retry", suggesting that the
notification should be sent back to the originating user so that *they*
can decide whether or not to retry. The local delivery agent shouldn't
automatically retry the message (or freeze it waiting for administrative
intervention).

I.e. Exim is correct in immediately bouncing a message when Cyrus
'deliver' reports that the target mailbox is over-quota.

(From practical experience it also often seems the only way to get users
to pay attention to quota limits is to bounce their mail so that their
correspondents can contact them out-of-band and put some peer pressure
on them!)

I can sort of see EX_CANTCREAT errors being retried, though even then I
think it's a disservice to the sending user to keep a message in the
queue in hopes that someone will take local action to allow it to be
delivered, especially if there's any chance that the local action might
take more than just a few hours to occur.

Take for example the situation where a user might have configured an
alias or a ~/.forward file, etc., to deliver to a file, but has failed
to make it possible for the mailer to write to that file. In this case
all messages could get stuck in the queue (and bounced because a retry
duration has expired) until some other human notices the problem.

The easiest way to get a human to notice such problems (be they
configuration problems or administrative limits) is to bounce the mail
right away and get the sender to apply out-of-band pressure to the
appropriate facilitator.

-- 
                            Greg A. Woods


+1 416 218-0098      VE3TCP      <gwoods@???>      <robohack!woods>
Planix, Inc. <woods@???>; Secrets of the Weird <woods@???>