McDonald, Ira wrote:
> 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.
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.
> The IETF ADs were right to complain about this. No printer
> vendor wants to figure prominently in the next CERT alert for
> security problems.
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...)
> 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).
Ah, and what is the job owner's email address, hmm? It usually
isn't "user at host.domain.com"...
--
______________________________________________________________________
Michael Sweet, Easy Software Products mike at easysw dot com
Internet Printing and Document Software http://www.easysw.com