EmailReception

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.

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?

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.

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

*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.

TerrelShumway?

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.

anthony, 2000-06-28: further thoughts

bob_sidebotham, 2001-01-03. Other possible uses

Owner: KenManheimer