[Exim] Sharing Experience

Góra strony
Delete this message
Reply to this message
Autor: James P. Roberts
Data:  
Dla: exim-users
Temat: [Exim] Sharing Experience
> > Ohhh, btw maybe Phil should implement the usage of the SIZE command
into
> > the callout-check, this could help with the mailbox full issues ....
>
> When the mailbox is full the address does exist. You should not bounce
> messages because sender's mailbox is full. At least I would not.
>


And I think you are smart to hold that position. Let me share a little
experience:

I once worked for a "large company" that implemented that policy
company-wide. That is, the central mail-server bounced any message from
an internal (employee) sender when the sender's mailbox was full. The
intent was to force employee's to clean out their mailboxes from time to
time. It was also meant as a front-line defense against disk overflows
(foreboding music interlude).

It eventually bit them in the hind-quarters, when an "unidentified
employee" arranged to forward a co-worker's emails, to a fax number,
when they were out of the office. The "fax-sending" feature was a
well-known and advertised feature of their mailing system. And so was
the "forward when out of office" feature. It was the combination that
caused the trouble.

It seems, the first message sent (an innocent "call me if you get this")
triggered a verification message from the fax-sending system. Which was
dutifully forwarded to the fax number, which triggered a verification
message... Well, needless to say, the co-worker's mailbox rapidly
filled with verification messages. Then comes the fun part...

Once the mailbox was full, the "bounce when full" policy kicked in. The
bounce messages were dutifully attempted to be forwarded to the fax
number, which generated a new bounce message, which was dutifully...
Well, you get the idea.

It is my understanding that the company email servers were taken down by
disk-space overflow. They were down for about 3 days, partly because
the event began late on a Friday. The "unidentified employee" even won
a mention in the company newspaper (which I kept a copy of... *grins*).

Anyway, my point in sharing is to (a) provide some amusement, and (b)
stress a few facts, that most of you probably already know, but it
doesn't hurt to repeat occasionally anyway:

Combining documented features of a product, in an undocumented way, no
matter how obvious, can produce unexpected results.

People will try pretty much every combination of features, eventually,
no matter how unreasonable it might seem to do so.

Think long and hard before implementing a policy that tries to control
human behavior.

Presume users will "hit every button, and flip every switch", even if
you put a big red "do not touch" warning on it. Even if you hit them
with an electrical shock when they touch it. Even if you hide it in the
basement, inside a locked cabinet, behind a door that says "Beware of
Leopard." Or something.

Never depend on M$ products for mission-critical applications. (Did I
mention the whole thing happened with a combination of M$ Exchange
Server and M$ Outlook?) CMA disclosure: This all happened quite a few
years ago, with "old" versions of these software; no doubt they've
"fixed" it by now...

I hope this is both enlightening, and mood-lightening.

Jim Roberts
Punster Productions, Inc.