|Version 9 (modified by 5 years ago) (diff),|
Pluggable email handler for Trac
provides a command line script and extension point that allows email messages to be handled by Trac plugins. This ticket provides a command-line script,
mail2trac which may be called by an MTA (e.g. postfix) to open a Trac environment and run through each enabled IEmailHandler and executes its
invoke() method if its
match() method returns
True. If invoke returns an email message, then subsequent
IEmailHandlers will also process the message. If
None is returned, then the message is consumed and execution stops.
To enable the plugin for
postfix, add an appropriate line to the aliases file (usually
/etc/postfix/aliases and then refreshing the aliases database (see man aliases). The
mail2trac script takes a
-p command line argument for the path to the project environment. The incoming email address should equal
[notification] smtp_replyto =
in the trac.ini file.
As an example, if
smtp_replyto is set to
firstname.lastname@example.org and the project is in
aliases file on
example.com should have a line like
foo: "| /path/to/mail2trac -p /var/trac/bar"
Processing mail from a third-party mailserver
If your Trac server lacks postfix and you want mail2trac to handle e-mail from a distinct server, you could use Fetchmail to download the e-mails and process them with mail2trac.
Example fetchmail command:
fetchmail --protocol POP3 --port 110 --user [mailaccount] --mda "mail2trac -p /path/to/trac/environment" mailhost.domain.com
Why not email2trac?
EmailtoTracScript is a more mature solution for converting email to Trac tickets. When building the GeoTicketPlugin, I was originally hoping to make use of the EmailtoTracScript to allow emails to specify a location in the subject header (see: source:geoticketplugin/0.11/geoticket/mail.py). When I realized the architecture would not easily support this, I thought of forking it, then realized that an implementation from scratch would actually better serve my needs.
- a real pluggable architecture that allows arbitrary email handlers to be plugged in
- POSTing to a URL to avoid complicated setuid issues with MTAs
- outside of configuring postfix and MX records (always fun!) an easy installation
While mail2trac is less mature, to the front-end user there shouldn't be considerable difference for the case of creating and responding to tickets. From a development point of view, I would recommend mail2trac over email2trac as a point to build on since a pluggable architecture was the point since the beginning.
If you have any issues, create a new ticket.
Download the zipped source from [download:mailtotracplugin here].