Question on implementing perl MIME::Parser using procmail/RHEL5.x(CentOS)
Linux - NewbieThis Linux forum is for members that are new to Linux.
Just starting out and have a question?
If it is not in the man pages or the how-to's this is the place!
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Question on implementing perl MIME::Parser using procmail/RHEL5.x(CentOS)
Hi folks,
I've been graciously provided with a script that should, when properly used, automatically strip out MIME attachments from emails and place them in a folder of my choosing.
problem:
I have no clue on how to implement this. This is a CentOS5.x server running sendmail/procmail and dovecot.
Any suggestions or pointers to recommended reading will be greatly appreciated.
Generally speaking the Local Deliver Agent (commonly procmail) can drive scripts from its recipes to manipulate e-mail contents. But in absence of the posted script, shouldn't you ask the person who provided the script for instructions instead?
Generally speaking the Local Deliver Agent (commonly procmail) can drive scripts from its recipes to manipulate e-mail contents. But in absence of the posted script, shouldn't you ask the person who provided the script for instructions instead?
Asked, but not yet answered.
The script is below...I should have thought to have posted it before.
Code:
use MIME::Parser;
### Create parser, and set some parsing options:
$archive='/path/to/dir';
my $parser = new MIME::Parser;
### Change how nameless message-component files are named:
$parser->output_dir("$archive");
$parser->output_prefix('msg');
### Parse input:
$entity = $parser->parse(\*STDIN) or die "parse failed\n";
The commentary was that this is used on individual messages delivered by procmail. For clarity, I'm needing to know how to have procmail run this when delivering mail to a particular local mailbox.
I could be wrong but it seems you only need to configure the $archive directory in the script, move the script to a directory that's in the globally accessable $PATH, add the "#!/path/to/perl" she-bang line and make it executable (octal 0755). Then your procmail recipe could look something like:
A first explanation of the recipe should be in 'man procmailrc; man procmailex' and I'm not sure you need a ":" lockfile. To test this you should copy a mailbox with messages containing attachments to another location, make certain $archive doesn't overwrite anything and invoke as: 'cat /path/to/mailboxcopy|formail -s|procmail -m /path/to/procmailrecipe', then check whatever $archive and /path/to/procmaillogfile was set to.
I added the required #!/usr/bin/perl, placed the script in /usr/bin, named it reports.pl. It is chmod'd to 0755. Added the recipe (after configuring the paths as needed). (btw, I'm doing this with webmin on CentOS 5.x)
Then, sending an email with an attachment, I get this in the defined log file:
Code:
# cat /var/log/procmail.log
procmail: Couldn't determine implicit lockfile from "/usr/bin/reports.pl"
procmail: Locking ".lock"
procmail: Executing "/usr/bin/reports.pl"
/usr/bin/reports.pl: line 2: use: command not found
/usr/bin/reports.pl: line 4: =/home/ray: No such file or directory
/usr/bin/reports.pl: line 5: my: command not found
/usr/bin/reports.pl: line 7: syntax error near unexpected token `('
/usr/bin/reports.pl: line 7: `$parser->output_dir("$archive");'
procmail: Error while writing to "/usr/bin/reports.pl"
procmail: Non-zero exitcode (2) from "/usr/bin/reports.pl"
procmail: Assigning "LASTFOLDER=/usr/bin/reports.pl"
procmail: Assigning "PATH=/home/ray/bin:/bin:/usr/bin:/sbin:/usr/sbin:/usr/local/bin:/usr/X11R6/bin"
procmail: Unlocking ".lock"
procmail: Couldn't unlock ".lock"
procmail: Locking "/var/mail/ray.lock"
procmail: Assigning "LASTFOLDER=/var/mail/ray"
procmail: Opening "/var/mail/ray"
procmail: Acquiring kernel-lock
procmail: Unlocking "/var/mail/ray.lock"
procmail: Notified comsat: "ray@7306739:/var/mail/ray"
From ray@server1 Thu Jul 3 08:09:27 2008
Subject: test3
Folder: /var/mail/ray
Also, I'm not certain how to ensure that procmail only saves the attachments for emails addressed to a particular email address. Seems like this may be instructing it to perform this action for all emails processed.
To reply to my own post, I now have read more (thanks unSpawn for the pointers!) and understand that the mailbox to be targeted is where the .procmailrc file goes...
I'm still not getting the desired results, but I'm closer and that's a tremendous help.
/usr/bin/reports.pl: line 2: use: command not found
Recipe and log look OK, so this sounds like your she-bang line points to the wrong location ('which perl') or it isn't the first line.
Quote:
Originally Posted by rsleventhal
Also, I'm not certain how to ensure that procmail only saves the attachments for emails addressed to a particular email address. Seems like this may be instructing it to perform this action for all emails processed.
You can expand your recipe with any filter criteria like from address, subject, body text.
understand that the mailbox to be targeted is where the .procmailrc file goes...
Hmm. That doesn't need to be true actually. While its common for user accounts to deal with their own delivery preferences in their own procmail recipes, you could actually have a central /etc/procmailrc and *still* deliver to users mailboxes. Anyway, if you encounter probs the log is the first place to look and if that doesn't show clues just post your revised recipes and log.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.