IPP Mail Archive: Re: IPP> 'mailto' Delivery Method for IPP

Re: IPP> 'mailto' Delivery Method for IPP Notifications

From: Michael Sweet (mike@easysw.com)
Date: Mon Jan 10 2005 - 09:44:14 EST

  • Next message: papowell@astart.com: "IPP> Mail Delivery (failure ipp@pwg.org)"

    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@host.domain.com"...

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



    This archive was generated by hypermail 2b29 : Mon Jan 10 2005 - 09:45:22 EST