Subject: RE: IPP> 'mailto' Delivery Method for IPP Notifications

From: "McDonald, Ira" <[email-masked]>
Date: Fri, 7 Jan 2005 10:57:29 -0800

Hi Gail,

[Nice to hear from you!]

The admin assistant use case still requires an LDAP verification
of the target.  Deploying a printer without this (even one that
does NOT accept jobs from outside the enterprise) makes it a 
potential spam engine.

The IETF ADs were right to complain about this.  No printer
vendor wants to figure prominently in the next CERT alert for
security problems.

I also think the admin assistant use case is a corner case.  It's
not what existing LPR email notifications do in the UNIX space
(they reply to the job owner).

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Blue Roof Music / High North Inc
PO Box 221  Grand Marais, MI  49839
phone: +1-906-494-2434
email: [email-masked]

-----Original Message-----
From: Gail Giansiracusa [mailto:[email-masked]]
Sent: Friday, January 07, 2005 1:06 PM
To: McDonald, Ira; Michael Sweet; Bergman, Ron
Cc: [email-masked]; Harry Lewis (E-mail)
Subject: RE: IPP> 'mailto' Delivery Method for IPP Notifications

Hi Ira,

I believe that one of the design points was to allow notifications to be
sent to a third party. The use case that was thrown around was the
ability of the notification to be sent to an administrative assistant to
be picked up.

Gail (Songer) Giansiracusa
Peerless Systems Corp
[email-masked]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
McDonald, Ira
Sent: Thursday, January 06, 2005 4:13 PM
To: 'Michael Sweet'; Bergman, Ron
Cc: [email-masked]; Harry Lewis (E-mail)
Subject: RE: IPP> 'mailto' Delivery Method for IPP Notifications

Hi,

Note that our IETF ADs observed that there are serious security
flaws in the 'mailto' Delivery Method for IPP Notifications.
These will need to be addressed in any PWG-ISTO standard.

Simplified explanation:  An IPP Printer MUST NOT accept any
subscription for 'mailto' notifications from an anonymous
IPP Job submitter - otherwise, the IPP Printer is a spam 
engine.  An IPP Printer SHOULD use an LDAP directory (or 
other authoritative source) to ensure that the recipient
of IPP 'mailto' notifications is in fact the Job Owner.

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Blue Roof Music / High North Inc
PO Box 221  Grand Marais, MI  49839
phone: +1-906-494-2434
email: [email-masked]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Michael
Sweet
Sent: Thursday, January 06, 2005 7:16 AM
To: Bergman, Ron
Cc: [email-masked]; Harry Lewis (E-mail)
Subject: Re: IPP> 'mailto' Delivery Method for IPP Notifications

Bergman, Ron wrote:
> 
> 
> Is there any interest in completion of this document as a PWG-ISTO 
> standard?

Yes.

> I am willing to take on this task if there is even a moderate
> interest. At one time it appeared that several companies were
> planning to implement this feature so there should be some support
> for a proper sandard.

The CUPS implementation will be ready for testing very soon, based
on the last draft.

-- 
______________________________________________________________________
Michael Sweet, Easy Software Products           mike at easysw dot com
Internet Printing and Publishing Software        http://www.easysw.com

---

From: Michael Sweet <[email-masked]>
Date: Mon, 10 Jan 2005 09:44:14 -0500

> does NOT accept jobs from outside the enterprise) makes it a 

Let's not forget that mailto also limits the kind of notifications
that can be sent to a low-volume subset (job completion, etc.), so
the potential risks are limited.

Also, I doubt we can do anything to validate that the
notify-recipient-uri is the job owner; the current advice to
check the notify-user-data attribute provides no protection against
spamming.  Even with authentication, there is no standard way to
map the authenticated user to an email address.

What we have been looking at implementing in CUPS is a basic
"allowed domains" filter, where the administrator will configure
the domains the client can send mailto: notifications to.  It
will be possible to allow any domain, but the default configuration
will be the local domain only.

> vendor wants to figure prominently in the next CERT alert for

Well, assuming that enough vendors implement mailto notifications,
and assuming that admins update their printer firmware and IP
configurations to enable it, then it is certainly possible this
could be an issue.  However, in practice this will not be an
issue unless a vendor provides a default configuration that
supporting email notifications out-of-the-box, and I know of no
vendor that does this...

In any case, since SMTP is inherently insecure there is no way we
can make mailto secure from spamming.  Since we are not publishing
an IETF standard for mailto, we don't have to live up to the
unrealistic requirements they are creating.

Instead, why don't we just require conforming implementations
to provide a validation of the notify-recipient-uri, and provide
examples, e.g.:

     - Require authentication, and map authenticated usernames
       to one or more allowed mailto: addresses

     - Limit notifications to a configured list of allowed
       recipients

     - Limit notifications to a configured list of allowed
       domains

In particular, the domain-based approach can be implemented with
very little overhead, and can be automated (connect to SMTP
server, say hello, get default domain name in response from
server...)

> (they reply to the job owner).

Ah, and what is the job owner's email address, hmm?  It usually
isn't "[email-masked]"...

-- 
______________________________________________________________________
Michael Sweet, Easy Software Products           mike at easysw dot com
Internet Printing and Document Software          http://www.easysw.com