Paul,
I sometimes wish that the IESG folks also took your simplistic view of the
world, but experience so far has tought us differently, especuially when it
comes to security. Let's see if we get a response from Ned Freed, who is the
new IETF Area Director with extensive IETF email experience. I am trying to
get any reactions from the Area Directors now rather than later.
Carl-Uno
> -----Original Message-----
> From: Paul Moore [mailto:pmoore at peerless.com]
> Sent: Tuesday, May 02, 2000 9:53 PM
> To: Carl-Uno Manros
> Cc: ned.freed; Carl-Uno Manros; ipp
> Subject: Re: IPP> How to prevent spam in email notifications?
>>> 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 at manros.com> on 05/02/2000 08:56:36 AM
>> To: "ned.freed" <ned.freed at innosoft.com>
> cc: Carl-Uno Manros <manros at cp10.es.xerox.com>, ipp
> <ipp at 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 at 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 at 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
>>>>>>>