• tag_path(tag_id) returns the full hierarchical path of a tag, with -> as the separator between branches.
• tag_depth(tag_id) returns the depth of the tag inside its hierarchy, starting at 1

As an example of use, in the custom queries of the user interface, we could use this query:

select mail_id from mail_tags mt join tags t on (mt.tag=t.tag_id) where tag_path(t.tag_id) ilike 'ParentTag->%'

to retrieve any message tagged with any tag whose top-level ancestor is ‘ParentTag’, no matter how deep the tag is inside the hierarchy (child, grandchild, grand grandchild…)

The upload happens on the server side: before passing outgoing messages to the delivery service, the plugin checks for attachments bigger than the configured size, and when found, transfers them to a web server, under a random-generated directory name. Inside the message, the contents are replaced by the URL pointing to them.

Until recently, the attachments had to be sent by FTP to the web server. What’s new is that it can now be SSH instead, provided that the Net::SFTP::Foreign Perl module is installed on the server.

The new version of the plugin comes with manitou-mdx 1.2.0 and is named attach_uploader_ssh.
(source code on github)

To activate the plugin and connect it to a sender’s identity, it needs to be declared in manitou-mdx configuration file.
Example:

[mymail@domain.tld]
outgoing_plugins = attach_uploader_ssh({host=>"www.myserver.tld", login=>
"sshuser", base_url=>"http://attached.myserver.tld", path=>"/var/www/attached.myserver.tld", maxsize=>2000000})

There is a “password” field that could be used but in this example it is assumed that an SSH key lets the script connect without a password. This is just one of the multiple security options and choices that open up when switching from FTP to SSH.

And here is how a picture larger that 2Mb would appear in the message (as a text/plain part)

The attached file is available at:

http://attached.myserver.tld/JXlafBybAKGrwE5yyOIbKA/PICT34.JPG

• More functions are available in the filter expressions: age(), date(), date_utc(), now(), now_utc(), identity(), rawsize().
• New equality and inequality operators for numeric comparisons.
• A mdx plugin to modify headers of outgoing mail with dynamic contents.
• A new incarnation of the attach_uploader plugin that supports ssh for file transfers.
• Migration to new Qt assistant and compatibility fixes for Qt-4.7 and 4.8.
• Drag and drop for attached files in the mail composer.
• A new dynamic column for recipients in the messages list.
• Many improvements in the filter editor: filters can now be reordered and tested from within the interface, and the user interface for actions has been redesigned.
• New filter actions: Set identity, set header, remove header.

So the question was, how to select all the messages tagged with certain tags, but excluding all threads for which at least one message has the Sent status? As usual, the database and the SQL come to help. First I looked up the tag_id’s of the tags corresponding to the mailing-lists, let’s say they were 3,6 and 10. And then I just expressed in SQL the sentence above. The result is:

SELECT mt.mail_id FROM mail_tags mt JOIN mail m1 USING (mail_id)
 WHERE tag IN (3,6,10) AND NOT EXISTS
 (SELECT 1 FROM mail m2 WHERE m2.thread_id=m1.thread_id AND m2.status&128!=0)

After issuing this query with the selection dialog, with the Limit To field empty to ensure that all messages are retrieved, all that was needed to accomplish the task was to select all the messages in the resulting list (Ctrl-A) and hit the Del key.

Additionally, the UI now uses the new full text search function for faster results.

This time, there’s a deb package for manitou-mdx that is expected to work with all reasonably recent debian/ubuntu releases, and another deb package for the user interface, which is created for ubuntu 10.
See the download page.

SELECT expr_id,name FROM filter_expr LEFT JOIN filter_log USING (expr_id)
 WHERE filter_log.expr_id IS NULL;

Now it may be that some of the filters returned by this query are new so that no hit on them occurred yet. We need to filter out these by adding a condition on the last_update field, requesting that the filter hasn’t been modified or created as new since at least 3 months.
Also, we only want entries from filter_expr that have actions tied on them, because filters without actions can be used as sub-expressions (that’s advanced filter usage) and don’t generate any hit.
With these additional conditions, the query becomes:

SELECT DISTINCT expr_id,name FROM filter_action JOIN filter_expr USING (expr_id)
 LEFT JOIN filter_log USING (expr_id)
 WHERE filter_log.expr_id IS NULL AND filter_expr.last_update<now()-'3 months'::INTERVAL;

With the query above we can check in advance what we’re about to delete.

Now, the deletion itself needs two steps, one for the filter_action table and another for filter_expr. Since both tables are joined in the query, we need a preliminary step to save the expr_id to delete into a temporay table. The SQL sequence including the transaction is:

BEGIN;
 
CREATE TEMPORARY TABLE del_expr AS
SELECT DISTINCT expr_id FROM filter_action JOIN filter_expr USING (expr_id)
 LEFT JOIN filter_log USING (expr_id)
 WHERE filter_log.expr_id IS NULL
 AND filter_expr.last_update<now()-'3 months'::INTERVAL;
 
DELETE FROM filter_action WHERE expr_id IN (SELECT expr_id FROM del_expr);
 
DELETE FROM filter_expr WHERE expr_id IN (SELECT expr_id FROM del_expr);
 
COMMIT;

To additionally delete the filters that haven’t been used for a significant period of time (for example one year), they could be added to our temporary table before the above deletion:

INSERT INTO del_expr SELECT expr_id
 FROM filter_log GROUP BY expr_id
 HAVING MAX(hit_date)<now()-'1 year'::INTERVAL)

Happy filters cleaning!