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.

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!

A typical reason to use different delivery agents when using different identities is that messages may have to be routed to different SMTP servers with different authorization methods. For example, some servers will simply reject messages that have an unexpected From address.
Also there are other cases such as messages from a GMail address that should be routed to a Google SMTP server in order to be signed with a proper DomainKeys header field.
Indeed, while it’s not mandatory, some receivers may pre-sort as spam or reject messages from GMail addresses that are not signed as the Google SMTP servers do with a DomainKey signature (not trusing these messages being the point of DKIM). Let’s see how to route messages written in Manitou-Mail from a GMail address to Google SMTP servers.
I’ve used msmtp for a simple, easy to configure Mail Submission Agent. esmtp is also a candidate but its debian package makes it an alternative to postfix and I happen to want it to supplement postfix, not replace it. msmtp, on the other hand, is a supplementary package that doesn’t conflict with the default MSA.

The procedure to use msmtp is quite simple:
Create a $HOME/.certs directory if none already exists.
Create a $HOME/.msmtprc file (with perm 0600) containing:

# gmail account
auth on
host smtp.gmail.com
port 587
user USERNAME@gmail.com
password XXXXXX
from USERNAME@gmail.com
tls on
tls_trust_file /home/daniel/.cert/ThawtePremiumServerCA.crt

Obviously USERNAME is to be replaced by your GMail login.
The cert file is to be extracted from the set of Thawte certificates available at: https://www.verisign.com/support/thawte-roots.zip, with this command:

unzip -p thawte-roots.zip 'Thawte SSLWeb Server Roots/thawte Premium Server CA/Thawte Premium Server CA.pem' > ~/.certs/ThawtePremiumServerCA.crt


And in manitou-mdx’s configuration file, we have something like:

[common]
# various things
[USERNAME@gmail.com]
local_delivery_agent = msmtp -f $FROM$ -t


UPDATE:

the mentioned certificate is no longer accepted, now we should use Equifax_Secure_CA.crt. I located the file in the debian package named “ca-certificates”, so changing my .smtprc to:

tls_trust_file /usr/share/ca-certificates/mozilla/Equifax_Secure_CA.crt


SELECT min(mail_id)
FROM header
WHERE position(E'\nFace: ' in lines)>0
GROUP BY
split_part(substr(lines, position(E'\nFace: ' in lines)+7, 1300), E'\n', 1)

position(…) let us know where the Face header field begins, substr(…) extracts a sufficient length of it, and split_part(…) cuts exactly the value at the first newline which marks the end of this header’s value (they’re unfolded in the header table precisely to be able to perform that kind of extraction).
Finally the GROUP BY ensures that each row in the result represents a distinct value of the Face header.

This query can be directly input into the SQL statement field of the Query Selection dialog, after which all there is to do is wait for the database engine to run it to completion.

On my sample database of about 800,000 messages from various mailing lists, it turned out that the result was a list of 176 messages. Here is a collage of a selection of the pictures (public messages only).

Here is how one particular message looks with its Face header:

Right now this is just about displaying, sometime in the future I’ll try to add Face headers to outgoing mail, and also I’d like to associate pictures to sender addresses so that messages from people who don’t use a Face header (the majority) still can be shown with a dedicated picture. I feel like even tags or sender domains (which means companies and organizations), could benefit from that kind of visual representation in certain cases.