IPP Mail Archive: RE: IPP> How to prevent spam in email noti

IPP Mail Archive: RE: IPP> How to prevent spam in email noti

RE: IPP> How to prevent spam in email notifications?

From: Carl-Uno Manros (carl@manros.com)
Date: Thu May 04 2000 - 17:06:39 EDT

  • Next message: Hastings, Tom N: "IPP> FW: Job MIB Bake Off and Status"

    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@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.
    >
    >
    >



    This archive was generated by hypermail 2b29 : Thu May 04 2000 - 17:13:24 EDT