IMAP support in Mail::Audit

Mike Bristow <[email protected]> Wed, 10 Dec 2003 11:48:27 +0000
Newsgroups gmane.comp.lang.perl.modules.mail-audit
Organization (none)
Message-ID <[email protected]>
Hi,

Recently my mail moved to an IMAP server, and I've written a (kludgey)
perl script to filter it into folders on the IMAP server.

Having done it once badly I think a better I have a better approach. 
It's better mostly so I can take advantage of things like SpamAssassin
and Mail::Audit plugins.  It goes sort of like this:

my $imap = new Mail::Audit::IMAPFactory( 
                                         server => 'imap', 
                                         user => 'mike',
                                         password => 'secret',
                                         # other things too, probably
                                        );

while (1) {
        my $mail = $imap->next_msg();   # blocks waiting for new mail

        if (not defined $mail) {
                die "The world has ended, oh, woe is me\n";
        }

        # $mail is a Mail::Audit::IMAP, subclass of Mail::Audit,
	# or something.
        eval {
                $mail->pipe("listgate p5p") 
                        if $mail->from =~ /perl5-porters/;
                $mail->accept("perl")
                        if $mail->from =~ /perl/;
                $mail->reject("We do not accept spam")
                        if $mail->rblcheck();
                $mail->ignore
                        if $mail->subject =~ /boring/i;
        }
        if ($@) {
                # we must have rejected this mail, or else the world has
                # ended in a more interesting way than usual
        }
}

But before I get stuck in, I'd like to see if anyone has any comments on
the idea - if there's an obvious problem, it may as well get spotted
early rather than late.

Is there a better approach to dealing with this other than subclassing
Mail::Audit?  

Obviously, such a system needs to never exit as a result of a problem
with a single message, but I think wrapping the filter in an eval will
do that; have I missed anything? 

Would it be worth adding a "batch" option to Mail::Audit to cover this
(and similar situations - I could argue that an
Mail::Audit::MailboxFactory would be useful for postprocessing mail once
it has arrived, too; perhaps to reflect you filter changes, or
something)


Cheers,
Mike