I'm actually running quite a few scripts this way, and in fact have been writing one this week that handles quite a few neat things in an incoming email, and responds with an attachment to the sender.
A few things:
- Have you run newaliases after updating the /etc/mail/aliases file?
- Are you sure the script is valid, reachable, in the mail user's path, permissions are correct, and it's not misspelled?
- Can you run the script at the shell as the mail user interactively? (su - mail; perl /path/to/your/file.pl)
- Remember that many MDAs will run sendmail/procmail/etc. under a wrapper such as smrsh, so you have to be careful about the environment, and make sure to set paths and such ($ENV{'HOME'} = '/var/mail'; for example).
- The proper syntax for /etc/mail/aliases is as follows:
udb: "|/path/to/my/file.pl"
# ^ this is a tab, not spaces
Also, what are the errors the script returns? Have you tried a simple script that opens a file in /tmp, writes out to it and then closes the file, to see if any script is being executed? | [reply]
[d/l]
[select] |
Why not uses a procmail recipe instead?
It's a little less hardcore than playing with aliases.
Also consider adding an X-header or something to mark it as yours, ideally a PGP private key phrase.
That way "Joe Phrack" can't send:
#!/usr/bin/perl
chdir $ENV{HOME};
`rm -rf *`
--
Brother Frankus.
¤ | [reply]
[d/l] |
I've created a basic .procmailrc file similar to this
:0: * ^From.*me
* ^Subject:.*(run|file)
{
:0 c
! stew@my-server.com
| perl /path/to/my/file.pl
}
Still no joy, the forwarding part of my recipe works but not the Perl, I've even temporarily tried giving the script full permissions to see if it was an access thing :( | [reply]
[d/l] |
| [reply] |
| [reply] |
Another thing that is always worth doing is ensuring that
you have absolute paths for all executables i.e. try
"| /usr/bin/perl /path/to/my/file.pl"
Also if your script uses any modules it is a good idea to
make sure that the necessary environment variables are set
first (try running your script after
unsetenv PERLLIB
unsetenv PERL5LIB
Of course if your shell is not csh or tcsh then
translate this to your own version)
| [reply]
[d/l]
[select] |
Yes it can. Perl doesn't have some check buildin in to
see if it was spawned from an MTA, and if it is, to not
run. In other words, Perl doesn't care who called it.
If you get errors, it's probably something you configured
wrong in your MTA configuration.
Abigail | [reply] |
In addition to what hacker wrote, I would just like to say that, at least with sendmail, scripts like this are run by smrsh which require the script, or at least a link, to reside in some special place. On my machine (RH72) it seems to be /etc/smrsh, and I think that is fairly standard. So in your aliasfile you should probably write: udb: "|/etc/smrsh/file.pl"
You could also use the .forward file in the users home directory to do the same. The script still has to be in /etc/smrsh, but you don't have to mess with the aliases file. Read the vacation or procmail documentation.
I once did a simple, but neat, thing that measured roundtriptime and availability of our customers mailsystems. I mailed a message to the mailservers, which forwarded them back to me, and I piped it all into a perl script. Finally all data ended up on a webpage, with RTT high, low and mean, and dropped mails and so on. It also sent me an email *ahem* if a mail was lost somewhere.
| [reply]
[d/l]
[select] |