Death by Sieve

[Mike Brodbelt]

Hi,

The following story happened to me on Friday - it's posted here for
amusement and edification, and also because I have a nagging feeling that
the software ought to be able to do something to prevent this sort of
thing, though I'll admit I'm not entirely sure what.
Some background - I run a cyrus server (2.0.16) for about 50 users.
Postmaster mail goes to two admins. One of our users left on Friday
evening, and it was necessary to bounce email to that user. As we wanted
people mailing her to redirect their messages to a colleague, we chose to
accomplish the bouncing with a sieve script, which rejected all mail, with
an explanatory note.
Some time later, my admin colleague, who was having a slow day, decided to
add a reject to her own sieve script, for messages above a certain size.
These would be rejected with a note to not send her large attachments.
However, a mistake was made in this script, and it ended up bouncing all
mail not caught by a preceding filter.
At this stage, one of the two participant (I'm not yet sure which) managed
to send a mail to the other. With Sieve deflector shields operating to
make Scotty proud, the resultant message ping-ponged between them, each
trip adding some more text to the message, and eventually died as the MTA
(sendmail) generated an error.
At this point, sendmail politely sent the problem message to postmaster
(by way of MAILER-DAEMON alias expansion). Unfortunately, the mail for
postmaster was delivered to me, and also to my colleague with the
problematic sieve script. And so another infinetly bouncing message was
born - this time both ends of the bounce being different aliases for the
same email address.
The net result of this was that every time sendmail ran the queue, I (as
the  unlucky sod with no shields up :-)) would receive about 3000
messages, each about 1.7Megs in size. My cyrus.cache file grew to over 2
gigs, and cyrus started refusing to talk to me any more.
After a couple or three queue runs, I'd figured what was going on, and
managed to remove the messages, reconstruct my mailbox, and delete the
unprocessed mails from sendmail's queue to prevent it restarting, so it's
all OK now.
However, should there not be some way for cyrus's sieve implementation to
avoid this. Perhaps it would be enough for sieve to refuse to process a
message that contained a header indicating that another sieve instance had
already processed it? Perhaps the reject action should add a special
"rejected" header, and not reject mail that contained that header? On this
occasion I fixed the problem, but at the rate it was going, if I had not
noticed the problem before leaving, it would have filled the mail
partition within about 6-8 hours.
Clearly, any user who receives postmaster/MAILER-DAEMON mail should under
no circumstances be able to reject this mail with sieve, so maybe the
answer would be that the sieve implmentation should refuse to send mail to
MAILER-DAEMON. There are still holes in that (other accounts that alias
out to the same person), but it would perhaps get rid of some of the
possibilities for mayhem....
Anyway, hopefully I've provided something to mull over, (and laugh at over
beer).
Mike.