Archive

Archive for October, 2009

Routing outgoing mail in manitou-mdx

October 18th, 2009 Comments off

The default command invoked as the delivery agent for manitou-mdx is `sendmail -f $FROM$ -t` where $FROM$ is replaced by the sender’s email address, which matches whats is called the sender’s identity in Manitou-Mail. On a typical Unix system, this command generally corresponds to the Mail Submission Agent that is installed and responsible for routing the outgoing messages. The sendmail name doesn’t necessarily imply that the MSA is the sendmail SMTP server itself, it can be postfix, or exim, or esmtp, or other programs that have adopted the same name and command line arguments for historical reasons and for the sake of interoperability.
Anyway in manitou-mdx, if this default command is not suitable, the administrator can replace it either globally, or per sender’s identity. A sender’s identity is declared in manitou-mdx configuration file by simply declaring a mailbox with its email address. In the Manitou-Mail user interface, the sender’s identities are configured in the preferences and choosed in the composer.

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

Categories: Usage Tags:

Face header support

October 7th, 2009 Comments off

While the X-Face header (48×48 BW picture) has been supported for a long time in the Manitou-Mail user interface, the Face header (48×48 color PNG) was not until yesterday.
Now it is, and while testing the code, I’ve found that it was another case where an SQL query quickly solved a practical selection problem. The Face header is indeed not so widely used, so getting a significant sample of different pictures to show is not obvious. Ideally I wanted to extract from my mail archive a gallery of pictures that would be all different. That is, if someone had posted 1000 messages with the same Face header, I wasn’t interested in getting all those messages, only one of them, let’s say the first by it’s ID, and I wanted the next mail in the list to be with a different, non-empty Face, and so on for every message that I wanted to look at. It turns out, that in SQL, it can be expressed with:

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).
face-gallery
Here is how one particular message looks with its Face header:
face-sample-msg
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.

Categories: New features, Usage, User Interface Tags:

Repackaged windows client available

October 3rd, 2009 Comments off

Since HTML viewing has been integrated, I’ve had reports that under Windows, the images in messages weren’t always displayed, but my attempts at reproducing the problem were unsuccessful.
I’ve recently understood that it was a packaging issue: on machines that don’t have Qt installed, image plugins must be distributed with the application (except for PNG that is supported as built-in).

So I’ve repackaged Manitou-Mail 0.9.12 for Windows with the necessary plugins that get installed into an imageformats directory, and re-uploaded the installer:
Manitou-Installer-0_9_12.exe

For users who were concerned by this problem, I suggest they reinstall and report if it still doesn’t work.

Categories: Uncategorized, User Interface Tags: