I still fail to understand what the spam issue is. Are you worried that a
shipping commercial product will start sending massive amounts of email to a
client machine. This sounds like a malicous product - who would build such a
thing (this is not like a virus you can send out - its a lump of hardware or a
piece of softwre that I have actively chosen to install, just uninstall it).
Even if you can imagine scenarios where this could happen (I cannot) mandating
that people include sender addresses will not work. People doing deliberatley
bad things will just ignore the specification and send the email anonymously.
Anyway If I wanted to spam you I can simply send you email from an email program
(it happens today) why would I bother using IPP.
Maybe you are concerned about people accidentaly configuring the printer such
that it will send too many notifications. I think calling this 'spamming' is
misleading as that suggests a deliberate act by a malicous or irritating third
party.
In this case I cannot see the issue either. The purpsoe of sending the email is
to clearly notify the receiver that something has happened at a resource that is
clearly identifiable - who would send anonymous / ambigous email notification.
I.e no commercial product is going to send
"something happened somewhere", they will send "Printer xyz (Xerox 1234 printer
near library) is low on toner" - this can clearly be traced back to the device
that sent it and an administrator can investigate if these are being send
incorrectly.
There is no way that any system design can distinguish between a good and a bad
configuration - it cannot know whether or not I asked the admin to set it up so
that I receive a copy of every email notification that a device sends out. The
only way would be to invent outrageously complex mechanisms - for example when
someody issues a third party email subscription to the printer it sends another
email to the destination user and does not actually activate the subscription
until it receives a response back that confirms this is the intent - but that is
just getting out of hand. How would the device know that the message had really
come from the intended user - maybe we could have it digitally signed just to be
sure,.. how can I as the receiver of this message know that its really coming
from the printer it says it is? does the printer time out the response from the
user? then retry? what if the receiving application is in fact an application?
(a definite possibility) .....
This is a printer, not an email system - just subscribe and send. The rest will
sort itself out.
Carl-Uno Manros <carl@manros.com> on 05/02/2000 08:56:36 AM
To: "ned.freed" <ned.freed@innosoft.com>
cc: Carl-Uno Manros <manros@cp10.es.xerox.com>, ipp <ipp@pwg.org> (bcc: Paul
Moore/AUCO/US)
Subject: IPP> How to prevent spam in email notifications?
Ned,
You already answered our earlier question about UTF-8 and email, thanks.
I have a couple of more questions in this area, before we can finish up our
draft on IPP notifications over email.
When using email to return notifications about print jobs, we are aware that
there is an apparent spamming risk, also pointed out in an earlier IPP
meeting by John Klensin. How can we best try to protect against that,
without having to re-invent or re-design email all together, or drop the
idea of doing notifications via email?
Here are some ideas that have been discussed in the group, but around which
we have not yet reached consensus:
1) Mandate the inclusion of an email address for the subscriber, when
notifications over email are requested by a subscriber. This could
potentially be validated by the printer (or print server) before accepting
the subscription. The idea would be to also include the subscriber's email
address in each notification.If we did that, which email address field would
be appropriate? The REPLY-TO:? As an alternative/addition we could
potentially mandate use of security e.g. Digest Authentication for
subscription operations, but it would still be useful to have the subscriber
address in the notification message.
2) The next question is whether we should require some kind of validation of
the email address to which the notifications are to be sent? We are talking
about the email address in the form of a URL malto://... Are there any rules
on how you could screen out DLs for use as email addresses? If you ask to
have printer state notifications to a large DL, you could easily generate
enough traffic to spam a whole domain in no time etc. etc.
3) Another question is which SENDER address you should use in a printer
generated email notifcation? Some people have argued that it should be the
name of the printer itself e.g. printer-22@foo.com, but it is highly
unlikely that the printer actually has an incoming mailbox and hence you
would have an emaill address to which no replis can be sent. An alternative
would be to use the email address of a person associated with the printer
e.g. joe.blo@printer-22.foo.com. Any recommendation on this?
4) Do you see any reason at all for a printer to generate email notification
messages asking for delivery notification? It could be done as a matter of
implementation, but we believe that it would be an overkill. Should we just
ignore it?
Hope you can give us some guidance on these subjects.
Carl-Uno
This archive was generated by hypermail 2b29 : Wed May 03 2000 - 01:01:44 EDT