I wonder if anybody has had any luck using Procmail (or any other method, but I think this is the way to go..?) to get Perl scripts to run in response to incoming emails?
Although Westhost don't provide tech support for Procmail, they do have v 3.22 installed which is A Good Thing! After reading other topics, including this one http://forums.westhost.com/phpBB2/viewtopic.php?t=151 I have had success in forwarding mails by doing the following:
1. Don't have a .forward
2. /home/username/.procmailrc reads:
LOGFILE=$HOME/procmail.log
VERBOSE=yes
:0c
! myotheraccount@hotmail.com
3. chmod 0644 .procmailrc
This forwards a copy of every email on to my Hotmail account, and presumably means that other forwarding recipes will work too (I haven't tried, this isn't what I want to do).
:idea: I was hoping to change the last line in (2) above to read
|/usr/bin/perl /home/username/www/cgi-bin/incoming/triggerscript.pl
:cry: It doesn't work. All that happens is I receive the email through my catch-all account. The script remains very, very untriggered.
:? Funny thing is, I saved a blank email as "testmail.eml" in my home directory, then issued this through SSH:
cat testmail.eml | /home/username/www/cgi-bin/incoming/triggerscript.pl
:!: Whaddaya know? It works! But the problem remains - how to automate it with Procmail.
Has anybody out there had a similar problem? Any thoughts, ideas or solutions greatly appreciated! Thanks!
2) Have a look at this post: http://forums.westhost.com/phpBB2/viewtopic.php?t=18 He is also redirecting to a Perl script, but he does not have /usr/bin/perl... Maybe it's redundant? Also, maybe you need a space after the |
3) Have a look at your procmail log... Seeing as you set VERBOSE=yes, it might give you a clue as to what is wrong.
4) Maybe you need to change the permissions on your Perl script?
First I'd like to thank you both with your efforts toward trying to solve this problem. Unfortunately I'm still playing detective, despite trying many variations on the recipe as suggested in various forum and web articles.
Design64, your four points are all good....
1. I'm pretty hazy on the PATH you give and its purpose, but a few articles mention it so I've incorporated it... Doesn't seem to help on its own though.
2. Yes I agree: I think the Westhost server doesn't need that rather stately "/usr/bin/perl" preamble, so it's best left out.
3. Yes the log does make interesting reading. It shows that only mails sent from within the system (ie by SSH or by Cron) are making it run. If I just email the domain, nothing appears in the procmail.log! Now that can't be right... It feels similar to the fact that I can "cat" a blank email saved on the system via SSH and pipe it into the file, and get the right result, but the script won't trigger by itself... It is as if mails from outside aren't making it through. Big, big clue - but I can't see how to use it to advantage!
4. Possibly, but I have all three 'x' and 'r' bits set and only owner 'w' bit... Same with the folder.
Jhalbrook, your links are most useful... The Linux-Mag one is a nice primer and makes me wonder if piping back through mail to the script internally is the answer, but also raises the issue of locking, quote:"We don't use procmail locking here; if the script does any writing to files, it will need to do its own locking (procmail locking is not recommended for this purpose)." My log file shows locking happens when cron sends me emails internally. I'm also given cause to wonder about procmail flags (-fbw anyone?) by the thread you reference...
My "best guess" is now:
PATH=/usr/local/bin:/bin:/usr/bin:/usr/local/bin:/home/username/bin
MAILDIR=/var/spool/mail/username
LOGFILE=${MAILDIR}/procmail.log
VERBOSE=yes
LOG="--- Logging a response... "
The >> bit isn't actually supposed to be on a new line; it's just been wrapped here. design64 is my username (and design64.net my domain, obviously).
My test.pl:
Code:
#!/usr/bin/perl
while (<>) {
print $_;
}
.procmailrc is CHMOD'd 644, and my test.pl 755 (775 also works).
Here's what I think:
* Check your permissions again
* Maybe you can't keep a copy of a mail being sent to a script (i.e. the c flag might need to go) and/or you need to have a lock file (one named by you or a default one. In the case of a default one, just add a second colon as above)?
* Maybe your Perl script is buggy? Did you upload it in ASCII mode? Try a simple script first (like mine above) and see if you can't get that working before you try something complex.
* And finally, what seems most likely: maybe your (old) condition had incorrect syntax. Try it exactly as I have above - matching on the To: header (you need to have "catch all e-mail's" turned on).
I tried e-mailing from two different programs using two different SMTP servers and it worked fine in both cases.
Hope this helps! If not, you might want to send me your Perl script and I'll see whether it works for me or not.
I just noticed you are using /var/spool/mail/ as your mail directory... This is not necessary. If you are not on a WestHost 2.0 server, this is actually incorrect in that we don't have access to this directory. You can name your maildir anything you want - I recommend using $HOME/mail. This way you have full access and your log file will be accessible too. I see, though, that you do seem to have access/rights to this folder - are you a new WestHost customer?
Hi D64, thanks for taking the time to experiment and reply!
I like your ideas, so I've put your Perl script up in ASCII format ( and checked that the other file is too - It was put up as part of a batch with other files which I know work). Chmod to 755 too, of course. The following works:
cat testmail.eml | /home/hypnosisdownloads/www/cgi-bin/test.pl >>/home/hypnosisdownloads/www/cgi-bin/test.txt
It creates a copy of the testmail.eml file in test.txt of cgi-bin as it should... but with the following _exact_ .procmailrc it's still no go:
PATH=/usr/local/bin:/bin:/usr/bin:/usr/local/bin:/home/hypnosisdownloads/bin
MAILDIR=$HOME/mail
LOGFILE=$HOME/procmail.log
VERBOSE=yes
I mailed to script@hypnosisdownloads to trigger the rule, and to my default address -- still not so much as an entry in the procmail.log
I too was wondering about the c flag and the mail address. Now it seems we've ruled those out - although the latter was clearly wrong ops: BTW I do have access to my mail file (the username after /spool/ ) but not the folder above it.
Looks like it might be locking then, because of writing to files (which your test.pl also does) although it is strange that it seems to be working for you without paying attention to that
I think next step is, I will of course repeat the whole uploading process forcing ASCII mode, but I think file locking might be the topic to zero in on.. any ideas on that?
I'll be here smashing my mind out with a slice of melon if anyone needs me :shock:
You say there are no entries in your Procmail log file - is it (procmail.log) at least created in the process (is it blank?!)? i.e. is Procmail itself working for you at all? If it is, it should not be created and left blank - it will at least have a few lines of what it did that caused its execution. Remember to name it properly (.procmailrc) no file name, the whole thing is just a file "extension"; uploaded in ASCII mode to your /home/username/ directory; and CHMOD'd 644, not 755/775. Try setting up a simple Procmail rule to ensure it's working and then proceed to debug the other stuff. I can't tell from your post whether your ">>/home/..." line is wrapped or if you actually put it on a new line - if it's the latter, that's incorrect... Move it back up to after the "| /home/..." line.
I doubt the problem is with lockfiles - if this was the case, the Procmail log would be filled with a "useful description" of what happened (e.g. the actions it took trying to assign a lockfile, if it failed, etc.). I did not bother with lockfiles or anything else other than what I posted above, and it worked 100%...
I am sure there is just a silly mistake somewhere in your code (or something)... That's almost always the problem I have :x
Good luck and let me know if you get it working or not!
There are entries in my procmail.log - but they only ever refer to mail that was sent from within the system. Ie, they refer to my Cron tasks, both of which send an email to my Westhost domain. .procmailrc-yes, that's the filename I use - hence 'hidden' from FTP progs but appears with a ls -a). Procmail.log says "no match on (condition)", "locking /var/spool/mail/hypnosisdownloads", "acquiring kernel lock", "unlocking /var/spool...", and "notified comsat: "hypnosisdownloads@325340:/var/spool/mail/hypnosisdownloads"". Then there's a bit of email header. This happens for every cron email sent, I think. (certainly for an hourly email I have going out.)
I did manage to redirect incoming mail using .procmailrc (witha !), but that's about it. I wonder if it's worth re-sending the email from within there ... but that's probably only going to confuse things. Oh yes, the wrapping - that shell command's all on one line, it was just wrapped in the forum. Sorry.
I will fiddle with it over the next couple of days afresh. I see what you mean about locking - if it works for you it should work for me. Therefore, there *must* be an obvious mistake somewhere... I may even try it on another server to see if I get results any different!
I'll let you know - Meantime, once again my thanks!!
I've just found (testing using the test.pl suggestion given above) that I seem to be able to trigger the script using internal emails (ie login via SSH and use mail command... mail hypnosisdownloads@westhost.net)
This seems to tally with the fact that other "internal" mails are working (ie the Cron tasks which send mails, as shown above - they come from "root").
Using my outside-westhost email address I have also just found that I can mail hypnosisdownloads@westhost38.westhost.net and this triggers the script via .procmailrc! Eureka! 8) :lol:
Wonder why this is the case though, and how best to use this new knowledge to fully solve the problem. Forward all mail to westhost38 address perhaps... Hmmm... :?
Procmail - Triggering Perl scripts with emails
Curiouser and curiouser...
Linear Mode
