ph10@??? (Philip Hazel) wrote on 26.06.00 in <Pine.SOL.4.21.0006260936180.28334-100000@???>:
> On Thu, 22 Jun 2000 sys044@??? wrote:
>
> > a. one message can be defered while another smaller one gets added to
> > the INBOX as the condition in src/transports/appendfile.c is
> >
> > if (saved_size + message_size > ob->quota_value ||
>
> Correct. The Exim quota acts in the same way that a system quota would
> act. This seemed to me to be what people would naturally expect.
> > Another reason given for this change is when a large document is sent
> > which can never be delivered due to quota limits but is "so urgent"
> > it must get through (grant application). This would allow
> > any message to be received provided the INBOX is not already
> > over-quota but with the normal consequences if it was not cleared from
> > the INBOX.
>
> Obviously, this kind of change could be made. But I would want to make
> it an option, because I'm not convinced it would be what people
> generally want. However, your example is not convincing. Once one "so
> urgent" message has got through, the next one fails. Where do you stop?
> Either you limit the mailbox or you don't.
>
> What do other people on the list think? Are there any more of you who
> would find an option to make Exim behave in this way useful?
That is exactly the way mail quotas work with T-Online (Germany's largest
ISP), so I suspect some people do find this useful - probably users more
than admins.
It means that mail larger than quota *can* be sent, but users get trained
to remove them quickly as they block receipt of any other mail.
I suspect that, OTOH, small systems don't want this to happen - over-quota
mail has much more severe consequences for 1 out of 10 users than for
10,000 out of 10,000,000.
MfG Kai
