> From: Steve Albin
> The normal, straighforward way to delete a bunch of queued emails would be one of these forms.
>
> To delete all frozen emails:
> exipick -iz | xargs exim -Mrm
In your case spam messages were queued, but not frozen.
"Frozen" is specific term in Exim. The -z option in `exipick` or `exiqgrep`
means frozen, not just queued. Thawing frozen messages requires
manual intervention.
I think that in your case Exim locked up because Exim couldn't log
to the same filled up partition with the spool. The term "frozen" is
misleading in such situation.
> exiqgrep -i -f username@??? | xargs exim -Mrm
>
> In all of the above cases, the "-i" argument causes exipick/exiqgrep
> to build a list of the relevant message ids
>
> They would be sent through a unix pipe to the exim delete command "exim -Mrm"
> with xargs managing small groups of ids at a time.
>
> Once I had the proper command form the first error encountered
> was that there were too many message ids so that the linux system
> could not build a pipe
I haven't much experience with Linux, but why'd Linux not able to build a pipe?
As far as I know, in FreeBSD a pipe is built in RAM, with a buffer of
limited size. Is it different in Linux?
> It would have been nice to prevent exim from beginning to send those
> frozen emails, because they were all spam, but I don't know how to do that.
Stop Exim daemon or cron job depending on how you run queue
(usually from daemon).
> The hacker who hacked one of my users' accounts
> spooled more than 350,000 spam emails for sending.
Additions to Exim config which automatically catch and block
such hacked user accounts:
https://github.com/Exim/exim/wiki/BlockCracking
These additions really freeze caught spam (with "control=freeze").
I modified that my code, now it doesn't allow spool partition
to fill up with spam. After half of free space becomes filled,
the code begins to reject instead of accept-and-freeze.
