Paul,
I agree with you that we can make recommendations for your case 1), but I
think preventing case 2) in your list would severy limit the functionality
of the notification mechanism.
If I send a thick document from LA to a printer in Tokyo, I want to notify
somebody in the Tokyo office who can go and pick it up there when it has
finished printing.
Carl-Uno
> -----Original Message-----
> From: Paul Moore [mailto:pmoore at peerless.com]
> Sent: Thursday, May 04, 2000 9:06 AM
> To: Carl-Uno Manros
> Cc: ned.freed; Carl-Uno Manros; ipp
> Subject: RE: IPP> How to prevent spam in email notifications?
>>> "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.
>>>