"Nobody is going to do that job for us. We have to list the possible threats
and then describe how we created a design which can protect against those
threats if not in perfect, but at least a reasonably good way. I have only
tried to sound out our Area Director how far he thinks we need to go."
I am not asking some third party to do anything - I am asking YOU to state what
one concrete issue is and then we can solve it. Spamming in general is a problem
of mail systems not of mail clients - the fact that SMTP is very loose about
what it will let through for example.
You do raise one potential problem that I think is valid. UserA can subscribe
UserB (or even DListC) to the page printed event of a printer. UserA has now
enrolled the printer as a spamming machine. I propose the following potential
solutions.
1. This is why email generalized notifications is a Bad Thing and we should
limit the set of email subscribable things to errors, job start and job complete
(that still cold be a lot of traffic - but it would be an order of magnitude
less)
2. The ability to email subscribe on behalf of somebody else is an administrator
only operation.
3. Do nothing - the person will get fired because their actions are traceable
(In the same way that we cant protect the printer against somebody pouring
coffee into it or sending us a job that contains 1,000,000 page feeds)
I think we should seriously consider #2 - its simple to implement and seems to
be a reaonable compromise. A given implementation can always turn the
restriction on or off.