On Mon, 16 Oct 2000, Drew Skinner wrote:
> Unfortunately, once a user receives a message that is over quota, no warning
> message is sent to the sender indicating that the end user is unable to
> receive the message. In fact the messages are invisibly queued without any
> notification to anyone that this has happened.
Well, if the user is over quota, Exim can't put anything in the mailbox
because it is over quota.
> Is there any other work around I could implement in the meantime (or
> (yikes)) have I missed something ?
Because of a request, the next release of Exim contains an option to
continue to deliver until the mailbox is *over* quota (as opposed to
behaving like a system quota and maintaining a hard disk limit). The
site that turns this on then has an entirely separate program that runs
as a cron job. It watches the mailboxes, and if it finds any that are
over quota, it stuffs a warning message on the end - knowing that Exim
won't ever add to an over-quota mailbox - provided the message isn't
there already.
If you know how users behave, you might guess one result of this - users
delete *just the warning message*, so they stay over quota, and the
system puts the warning message back again next time!
> They're aware of such things as :fail: and :blackhole: .Since I have
> given the control of these files back to the individuals that run the domains,
> several people have commented to me that it would be very useful to have
> another option in this file: :vacation:/path/to/vacation/file. I'm inclined
> to agree as this would nicely simplify things.
It's called "piping". You can do it like this:
alias: |/path/to/vacation/file
but you have to set a pipe_address_transport on the director to tell it
which transport to run.
Or do you mean that /path/to/vacation/file contains the message to send?
You could do that by passing it as an argument to the pipe:
alias: |/usr/ucb/vacation /path/to/vacation/file
--
Philip Hazel University of Cambridge Computing Service,
ph10@??? Cambridge, England. Phone: +44 1223 334714.
