Re: IMAP support in Mail::Audit

Sorry I haven't taken the time to fully read your email.

But have you thought about using Mail::Audit before the mail
actually hits your imap server?

I read my email via IMAP but before my mail has hit the IMAP
server it's invoked my perlscript which has used Mail::Audit
to filter the mail into the appropriate Mail Folders.

How much email are we talking about? Perhaps it would be easier
to write each existing IMAP folder to an Mbox file and then process
that via Mail::Audit and custom perlscripts.

Refiltering your email doesn't sound too difficult to me. But I woudn't
do it from an IMAP source myself. If you wanted to do that though just
use IMAPClient and process each message individually.

On Dec 10, 2003, at 5:48 AM, Mike Bristow wrote:

> 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
>
>
> _______________________________________________
> mail-audit mailing list
> [email protected]
> http://lists.netthink.co.uk/listinfo/mail-audit