To make things granualar a seperate parsing procedure should deal with loading the e-mail into the TCL interpreter and setting variables in an array for further processing. 

ad_proc parse_email {
    -file:required
    -array:required
} {
    An email is splitted into several parts: headers, bodies and files lists and all headers directly.

    The headers consists of a list with header names as keys and their correponding values. All keys are lower case.
    The bodies consists of a list with two elements: content-type and content.
    The files consists of a list with three elements: content-type, filename and content.

    The array with all the above data is upvared to the caller environment.

} {

}

Processed and put into the array should be:

HEADERS:

• message_id
• subject
• from
• to
• date
• recieved
• references
• in-reply-to
• return-path
• .....

X-Headers:

• X-Mozilla-Status
• X-Virus Scanned
• .....

As we do not know which headers are going to be available in the e-mail, we will just set all the headers we can find in the array. The callback implementation would then have to check if a certain header is present or not.

#get all available headers
set keys [mime::getheader $mime -names]

set headers [list]

# create both the headers array and all headers directly for the email array

foreach header $keys {
    set value [mime::getheader $mime $header]
    set email([string tolower $header]) $value
    lappend headers [list $header $value]
}

set email(headers) $headers

Body parts 

An e-mail usually consists of one or more parts. With the advent of complex_send, OpenACS supports sending of multi part e-mails which are needed if you want to send out and e-mail in text/html and text/plain (for old mail readers). 

 

switch [mime::getproperty $part content] {
     "text/plain" {
          lappend bodies [list "text/plain" [mime::getbody $part]]
     }

     "text/html" {
          lappend bodies [list "text/html" [mime::getbody $part]]
     }
}

Handling of incoming files 

Due to the fact that we support the tcllib mime functions, getting incoming files to work is pretty easy and straight forward. We just have to look for a part where there exists a "Content-disposition" part. All these parts are file parts. Together with the scanning for the mail body it looks something like this:

set bodies [list]
set files [list]

#now extract all parts (bodies/files) and fill the email array

foreach part $all_parts {
    # Attachments have a "Content-disposition" part
    # Therefore we filter out if it is an attachment here
    if {[catch {mime::getheader $part Content-disposition}]} {
        switch [mime::getproperty $part content] {
            "text/plain" {
                lappend bodies [list "text/plain" [mime::getbody $part]]
            }
            "text/html" {
                lappend bodies [list "text/html" [mime::getbody $part]]
            }
        }
    } else {
        set encoding [mime::getproperty $part encoding]
        set body [mime::getbody $part -decode]
        set content  $body
        set params [mime::getproperty $part params]
        if {[lindex $params 0] == "name"} {
            set filename [lindex $params 1]
        } else {
            set filename ""
        }
        # Determine the content_type
        set content_type [mime::getproperty $part content]
        if {$content_type eq "application/octet-stream"} {
            set content_type [ns_guesstype $filename]
        }
        lappend files [list $content_type $encoding $filename $content]
    }
}
set email(bodies) $bodies
set email(files) $files

Take a note that the files (attachments) are actually stored in the /tmp directory from where they can be processed further. Therefore it is up to the callback to decide if to import the file into OpenACS or not. Once all callbacks have been fired they will have to be deleted again though. 

Now that we have the e-mail parsed and have an array with all the information, we can fire off the callbacks. The firing should happen in two stages. The first stage is where we support a syntax like "object_id@yoursite.com". Then incoming e-mail could look up the object_type, and then call the callback implementation specific to this object_type. If object_type = 'content_item', use content_type instead.

ad_proc -public -callback acs_mail_lite::incoming_object_email {

-array:required

-object_id:required

} {

}

callback acs_mail_lite::incoming_object_email -impl $object_type -array email -object_id $object_id

 

ad_proc -public -callback acs_mail_lite::incoming_object_email -impl user {

-array:required

-object_id:required

} {

Implementation of mail through support for incoming emails

} {

# get a reference to the email array

upvar $array email

# make the bodies an array

template::util::list_of_lists_to_array $email(bodies) email_body

if {[exists_and_not_null email_body(text/html)]} {

set body $email_body(text/html)

} else {

set body $email_body(text/plain)

}

set reply_to_addr "[party::get_by_email $email(from)]@[ad_url]"

acs_mail_lite::complex_send \

-from_addr $from_addr \

-reply_to $reply_to_addr \

-to_addr $to_addr \

-subject $email(subject) \

-body $body \

-single_email \

-send_immediately

}

The object_id based implementations are mainly useful for automatically generated "reply-to" addresses. But with ProjectManager and Contacts it is also handy, because the Project / TaskID is prominently placed on the website. So if you are working on a task and you get an e-mail by your client that is related to the task, just forward the email to "$task_id@server.com" and it will be stored along with the task. HIGHLY useful :).

Obviously you could have implementations for:

• forums_forum_id: Start a new topic

• forums_message_id: Reply to an existing topic

• group_id: Send an e-mail to all group members 

• pm_project_id: add a comment to a project

• pm_task_id: add a comment to a task and store the files in the projects folder (done) 

Once the e-mail is dealt with in an object oriented approach we are either done with the message (an object_id was found in the to address) or we need to process it further. 

For this a general callback should exist which can deal with every leftover e-mail and each implementation will check if it wants to deal with this e-mail. How is this check going to happen? As an example, a package could have a prefix, as is the case with bounce e-mails as handled in acs_mail_lite::parse_bounce_address (see below):

Alternatively we could just check the whole to address for other things, e.g. if the to address belongs to a group (party)

Or check if the to address follows a certain format.

 Alternatives to this are:

• $component_name-bugs@openacs.org (where component_name could be openacs or dotlrn or contacts or whatever), to store a new bug in bug-tracker
• username@openacs.org (to do mail-through using the user name, which allows you to hide the actual e-mail of the user whom you are contacting). 

Cleanup

Once all callbacks have been fired off, the e-mail needs to be deleted from the Maildir directory and the files which have been extracted need to be deleted as well from the /tmp directory.