This amounts to needing to tell your local mail delivery system that instead of sending mail for a particular address to a user's mailbox it should instead be delivered to a process.

"Being delivered to a process" means different things. You could, for example, have the mail delivered normally to a mailbox and go through the mailbox with a perl module. But thats fugly. "We don't want to give you that".

If you've got a POP or IMAP server you could deliver the mail to a mailbox and then slurp it into a perl script using the Net::POP3 or similar module. Less ugly, but still too ugly to live. "But we don't want to give you that".

If you were using sendmail as your local mail delivery system, it honours something called '.forward' files. (This is UNIX, right?) I know you aren't using sendmail, but stay with me here.

You create a unix user id corresponding to the script you want to run and create a file called '.forward' in that user's home directory. The original purpose of such a file was so you could put another email address in here and have all your mail forwarded to that address.

Instead of forwarding to another email address you can instead put in the name of an executable command, for example a perl script.

The email gets handed to the process on standard input. Typically in the form of "headers + blank line + body". There are perl modules to help you grok these things.

The '.forward' concept applies to sendmail, but because of sendmail's previous ubiquity, is also supported by many other mail systems. I don't know if qmail is one of these but I would hazard a guess that it will either support this as is (i.e. it will 'just work') or grepping the qmail docs for '.forward' will help you.

Of course, there are probably better ways of doing this depending on a) how much access you have to the local system (above idea does not require root) and b) how much you want to read the docs.

For example, sendmail also supports configurable local delivery agents, so cool tools like procmail can be run more efficiently and securely by the mailer.

Basically its a qmail issue if you are using qmail. It will have some mechanism for delivery to a process and the above posted comments about reading standard input will then apply.

Have fun

open OUT, ">>mail.out" or die "Can't open: $!";
print OUT while <STDIN>;
close OUT;
[download]

#!/usr/bin/perl -w

use strict;

my $FIFO = "$ENV{HOME}/pipe";

while (1) {
    unless (-p $FIFO) {
    unlink $FIFO;
    system('mknod', $FIFO, 'p')
        && die "Can't make pipe $FIFO: $!";
    }

    open (FIFO, "$FIFO") || die "Can't open $FIFO: $!";
    while (<FIFO>) {
        chomp;
        print "Command sent: $_\n";
    }
    close FIFO;
}
[download]

On a side note:
Yeah, it only works on *nix... Notice the system()? Its pretty safe to say that whenever you do that, you're going to find serious portability issues.

Then again, I've never seen qmail for anything not *nix... :o)

However, if you're just wanting to put mail into a Mhonarc archive, here's some code I use to do that:

my $mhonarc = "/usr/local/bin/mhonarc"; # Path to Mhonarc executable
my $archive = "/home/httpd/html/archive"; # Path to archive
my $rcfile = "/home/httpd/mhonarc.rc";    # Path to Mhonarc rcfile

my ($m,$y) = (localtime(time))[4,5]; $m++; $y+=1900;

my $month = sprintf("%04d%02d", $y, $m); # make a directory name like 
+YYYYMM
    
unless (-e "$archive/$month") {
    mkdir("$archive/$month", 0775) || 
    die "Couldn't make new archive dir: $!\n";
    }

open(OUT, "|$mhonarc -add -rcfile $rcfile -outdir $archive/$month -qui
+et") ||
    die "Couldn't open mhonarc: $!\n";

while(<STDIN>) {
    print OUT;
    }
close (OUT);
[download]

i have qmail on a freebsd server, so my .qmail file looked like this:

|/usr/home/justin/wwwdev/cgi-bin/mojo/take_mail.cgi

and my little program looks like this: (lots of code... ok almost all the code from the soam article)

 

#!/usr/bin/perl 
#take_mail.cgi
use strict; 
my ($header, $body); 

my $recieved = "/usr/home/justin/wwwdev/cgi-bin/mojo/recieved.html";
my$mailprog = "/usr/sbin/sendmail";
{ local $/ = ""; 
 $header = <STDIN>; 
 undef $/; 
$body = <STDIN>; 
} 

open(MAIL,"|$mailprog -t");
print MAIL "From: <justin\@skazat.com>\n";
print MAIL "To: <justin\@skazat.com>\n";
print MAIL "Subject: perl wants to  says hi to you all\n\n";
print MAIL "header: $header\n";
print MAIL "body: $body\n\n";
close (MAIL);

and thats all there is too it, thanks everyone!

thats not what i'm asking ;) i want the other way... i want to send an email to perl and have perl do something with it, instead of using perl to send an email ;) think about majordomo, how you send commands to it by email and it gets back to you, that sort of stuff. it seems like a cool way to interact with a script.. or maybe just an old way...

Right. Did you look at my response? Try reading from STDIN.

By the way, you might want to rephrase your question-- it's not very clear (in fact, it's sort of meaningless) to say that you want to "send an email to perl". That just doesn't mean anything.

What you want to do, as far as I can tell, is to have all incoming email messages handled by a Perl script. So, for example, if I set up a Perl script to handle my mail, all incoming mail would be piped to that Perl script, and it could do whatever it wished with the contents of the messages.

You might want to take a look at Mark-Jason Dominus's My Life with Spam series. Part One is up on his site, but I can't seem to get to plover.com, so it's also on LinuxPlanet; Part Two and Part Three are both up on perl.com. The articles deal with filtering spam from your mail, but you may be able to get something useful out of them. Here's a part that deals specifically with how the mail message gets into your program.