Buscador - a dynamic mail archiver with a twist


Buscador is web based mail archival and retrieval tool based around the concept of Intertwingle :

In essence it provides a variety of different views on the mail using a system of plugins. Plugins provided include ones to show thread views, date views, seperation into mailing lists, extraction of named entities and Atom feeds for recent mails, per thread, per list and per person and for handling mailing.


Buscador is distinctly ALPHA level software and details of its architecture could change at anytime. Be prepared for DB changes and plugin system gutting and rebuilding by reading the safety card in the pocket in front of you and bracing you hands over your head in the event of catastrophic architecture rethinking.


Install dependencies

There's a Bundle::Buscador available from

however some people have had problems installing some of these. Namely


And, in particular SQL::Translator. SQL::Translator installs a lot of weird things such as GD, Graphviz and Spreadsheet::ParseExcel.

A cut down version of SQL::Translator without these dependencies is available from

Create config file

Make a directory in your web root, cd into it and do

    % buscador -init

this will copy some templates and some images into the directory and then generate a sample config file. You should edit the config file.

You might want to move your chrome directory outside your new buscador directory and alter your config accordingly. That way Maypole (which Buscador is based on) doesn't try and first see if there's a table called 'chrome' before passing through to the actual chrome directory and also won't fill your logs with errors.

Import some mails


        % buscador -setup

and then

        % buscador /path/to/mail/folder

Create Apache config

Something like

   <Location /buscador>
        SetHandler perl-script
        PerlHandler Buscador

but changed to whatever directory you wnat to install it under.

If you're using the default SQLite db remember to make sure that the web server has enough access to read it and get a lock.


The plugin system is based around Module::Pluggable::Ordered. Each plugin get the chance to influence the path being passed in. The order that they are called in is set by the parse_path_order method, the lower the return value the higher the priority. For example:

    package Buscador::Foo;

    # we're middling important
    sub parse_path_order { 13 }     

    sub parse_path {
        my ($self, $buscador) = @_;

        # buscador is an alias for search
        $buscador->{path} =~ s!/buscador/!/search/!;


however they don't have to touch the path at all and can simply install methods in other namespaces;

    package Buscador::Bar;
    # this is where path parsing methods would go

    package Email::Store::Mail;
    use Fortune;

    sub bar :Exported {
        my $fortune = Fortune ('fortunefile')->read_header()->get_random_fortune();
        $r->{template_args}{fortune} = $fortune;
        $r->{template}               = "fortune";


And now, if we write a 'fortune' template and go to

we'll be presented with a fortune.


Lots and lots. And then some more

UTF8 doesn't work properly.

This needs serious testing.

The templates are ugly.

I have a vague design in mind. We could also do with having themes.

see TODO file


Originally Simon Cozens, <> Now maintained by Simon Wistow, <>


This module is part of the Siesta project -

There is a mailing list at (subscribe at

SVN/DAV access is available via


Copyright 2004, 2005 by Simon Cozens and Simon Wistow

This library is free software; you can redistribute it and/or modify it under the same terms as Perl itself.