History for EmailReception

??changed:
-
  Currently issue creation and responses are submitted only via the
  web. Notices about new posting are sent to all concerned parties via
  email, but we would like to provide for conduct of all tracker
  correspondence via email, as well.

  As with workflow mechanisms, even moderately general facilities for
  doing this - mechanisms for conducting email into zope, and for
  associating them with the right existing threads, recognizing new
  ones, and having provisions for unhandled ones - could be of wide
  utility to Zope users.

anthony

  I'd like to try and seperate the issue of the general "email into zope"
  from the "email into Tracker" issue. The former is a rather large and
  complex beast, while the latter can be handled in a somewhat smaller
  way. 

  *StephenHarrison 2000-07-06* -- *On the general "email into zope" issue.*

    *In case you are not aware, we (NIP) have been working on a ZMailIn
    product, the first very basic version of which is available from
    http://www.zope.org/Members/NIP/ZMailIn/ (the announcement to the 
    mailing list can be found at http://zope.nipltd.com/public/lists/zope-archive.nsf/ByKey/F3880B7693C740A8 ).
    We will shortly be releasing the next development version which has more
    functionality and uses XML-RPC.*

  A first, simpleminded, approach

    An email alias which passes the messages through a ZClient or
    XMLRPC enabled python script. This script looks for a number of
    headers.

       First of all, it can pull the issue from the subject line
       (assuming it's been left un-mangled).

       Next, it can look for a header like 'X-Tracker-State' or the
       like that the user can enter - this is an action such as
       'resolve' or the like. If it's not present, the default of
       'plain' is selected.

    How does this sound?

    *klm, 06/26/2000* -- *It sounds good.  A few things to consider:*

      *Probably something will need to be done to provide for errant
      email messages, that don't find their issue.  Maybe a
      lost-and-found page for the admin and the supporters to
      "manually" direct the stuff to the right (or new) issue.  The
      trick will be to do something adequate while avoiding doing
      anything too ambitious.*

      *My plans for message metadata - actions, in followups, and
      traits, for initial messages - were to do something rfc822-ish
      within the body of the message.  The first few lines of the
      message would be reserved for lines that started with the field
      tyep - "Action: ..." and "Traits" - followed by a blank line,
      followed by the body of the message.  Absence of any of those
      fields, or of the metadata section entirely, will invoke
      defaults, not errors.*

      *How will you handle unifying the message sender with the site
      member?  Email address?  Maybe a field in the header or metadata 
      section for "Member: ..."?    As with handling errant messages,
      how can this be done simply?*


TerrelShumway

      *Would something XML-ish be better than something RFC822-ish?
      XML is easier to validate and harder to break as the schema
      becomes more complex.*

      *For example, "configuration" may start out as something very simple,
      such as `uname -a` and progress to a full list of installed packages
      and versions.  I believe XML would handle this development much
      better than simple name:value lines.*

      - klm 07/05/2000 - Really, people shouldn't have to mess with
        email message headers!  I feel pretty strongly that using
        *simple* special formatting in the message body is the right
        thing.  

        And i would not begin to think XML is the right thing when
        we're talking about attribute/value pairs!  XML was made for
        comprehensive structure encoding, and is way *way* too
        elaborate for people wanting to say::

          type: bug
          urgency: high

        In general, it will be hard enough to get people to reliably put
        dead simple cues in their message.
        <shudder> XML </shudder>.

      *Putting the meta-data in the message body rather than the header
      will make you a hero to people with brain-dead MUAs.*

*anthony, 2000-06-28* -- *further thoughts*

      *A reply without an issue (remember, we're pulling it from the
      "Subject:" line, so it's going to be there most of the time) could   
      create a new issue, and a supporter can just
      divert it to the appropriate place. Hm, that's probably not quite
      enough - what's needed is a 'divert and move' or something. This 
      also allows new tasks to be added simply (admittedly, without any
      meta-data, but hey, they can be edited.*

      - klm July 5, 00 - Ultimately, it would be nice if the zope email  
        sender had a way to track the outgoing message ids, so it could
        use the "in-reply-to" header many MUAs use, in addition to the
        subject line.  The more info, the better, for this task.

        Re resituating an errant reply with its issue, it would be nice to
        put unplaced messages in a special place, rather than just creating
        issues for them, and having to deal with the empty husks after the
        items are redirected to their real homes...

      *Putting meta-data in the body as a name:value is probably a better
      idea than relying on people to have a sane mailer. I don't like the
      idea of forcing people to know XML to just close a simple problem.
      At the bottom end of the simplicity scale, I want someone to just 
      be able to receive an email about a minor bug or whatever, and just
      be able to type in*

         "Action: resolved"
       
         "This has been fixed"

      *and it will just close the task*

      *email address to user name can be done from the member email
      address - maybe allow alternate email addresses in a future user
      database?*

      - klm 07/05/2000 - Good idea - members are recognized according
        to the senders email address, and the list of addresses the
        member has.  I guess this would be a PTK kind of thing -
        member preferences, and so forth.

bob_sidebotham, 2001-01-03. Other possible uses

   I have an application where customers are used to sending email to
   a specific address to request special services. For this application,
   I obviously can't require that the customers do any generic formatting,
   so I would like to be able to route the mail purely on the customer's
   email address. In this case, each "tracking issue" is the "set of
   action items for a specific customer".

   Ideally, I'd like to see an extensible set of processing rules for
   email in. So if someone wants to do it via content, and someone else via
   the sender's address, so be it.     


Owner: KenManheimer