Student projects/Email interface

Programmer: Peter Boswood

(This is very much still a work in progress, data here may be inaccurate or outdated!)

Summary

Moodle uses email in order to communicate with end users in a variety of manners - for authentication, subscriptions in the Forum module, etc. In some instances, rather than simply ignoring replies from users to these emails, it may be possible to "interpret" them intelligently, carrying out specific actions depending on the Module that sent this email.

Previous Work

Moodule currently has functions to allow for dealing with handling email bounces - see Email processing for more details. This framework allows for the module of a returned email to be uniquely identified, as well as arguments to be passed as part of the email that will be supplied to the module's handling code.

This framework currently uses base64 encoding in order to encode data used in the return address of the email - this requires case sensitivity, which most MTA's do not support by default. This will need to be changed to use base32 instead, which significantly decreases the amount of space avaliable in the argument section. This can be mitigated using a "email session cookie table", as suggested here.

Database structures

A database table will be neccesary in order to keep track of the relevant data attached to each email "session". A simple sample design is provided below:

mdlEmail_Sessions:

• Session ID : Key field - this must be big enough to store the maximum values referable by a 42 character base32 encoding. This will match the "argument" field of the email's return address.
• Data : VarChar (or otherwise?) field to store data of any length mapped to this email session. Is there a significant performance hit to using VARCHAR over fixed length CHAR?

By uniquely identifying each email by a session ID, we can solve the problem mentioned of handling repeats by removing the appropriate row from the table after the handler has run. Replies without an appropriate row could simply be discarded.

Core functions

• Framework - non-module code to support framework of the email interface.
  • Functions handling email sending - encoding of the reply-to address header.
    • Currently implemented as generate_email_process_address in lib/moodlelib.php.
    • Could be changed to something more specific - e.g. generate_email_session?
  • Functions handling email recieving - decode of the destination (reply-to) header.
    • Currently implemented as the command line mail parsing script admin/process_email.php.
    • This currently handles bounces as well as decoding and calling appropriate modules, and may not need to be changed much.
• Module code - changes to specific modules to actually use the email interface.
  • Forum module
    • Subscribers to forums recieving "single messages" can have their emailled replies directly added as a reply to that specific post.
    • Subscribers to forums recieving "digest messages" may need some further interface to specify which post they are replying to, e.g. "3>>Message".
  • (Investigate other modules)

Major tasks

• Change configuration files (config-dist.php) to include constants for activation of the entire interface - same section as the handling of bounce messages. This should include documentation for them.
• Finalise table structure for the email session handling, if we use it.
• Creation / Modification of functions to handle encoding data - including insertion into the session table.
• Creation / Modification of functions to handle decoding data - from a session table, checking the appropriate hash. This will require us to change admin/process_email.php yet still retain the ability to handle bounces.
• Creation of a forum_process_email function within the Forum module to allow for action to be taken upon receipt of a message (reply) from a forum subscriber.
• Modification of the Forum module to pass data about the specific post(s) being sent, possibly by the session table.
• Look into how to better handle "digest"-style messages?

Timeline

July 9th should be a milestone (mid-term evaluations) for the completion of the framework and most (if not all) changes to the Forum module. The period after that (till August 20th) can be used for further changes and refinements to the framework and other modules. Hopefully this can be updated as further details become apparent.

Back to: Student projects