Run PHP script when new email received

I have been looking around for a solution to this, i have been developing for a wile though am very new to CGI, PHP and a lot of the web based tech.

I have a web site hosted with a cPanel web host.

I am looking to have a script(prefer PHP) to run everytime i get a new email to help@xxx.com. The script that i was hoping run will update some vars on a sql data base.

I know how to accomplish all the tasks with PHP, the only part i am trying to figure out is how to tell my web server to run the script when a new email is received.

currently running a cron job and would prefer to not run the script every min and only when relevant.

Don't need a solution i like to do my own work, a point in the right learning direction would be nice.

procmail

1 Like

I think your cron is the right track, but tastes vary.

You can check your mailbox file not empty very easily, and if there is mail, popen a mail command to read it or whatever.

A longer term cron is fine if it just restarts a looping script if not already running.

1 Like

don't want to have a looping solution. Already doing that in the mean time and am trying to move to something a little more real time. How would i set the cron to check if the script is running or not?

@nneo
found something else on procmail another post stated
'got the result i'm looking for through .procmailrc in the ~/ directory of the user'
if that is what you are referring to then i can not find ~/ dir.
Just a reminder that i am using a cheepo web host. so i dont have root access.

I found this post that might be in the right direction
though i am not aloud to post the URL at the moment
this is the there sugestion
Look at using the /etc/aliases file - you can pipe the incoming message to a specific user into a program (or script)

looking @ my /etc/aliases is not there. So not sure how i would continue to use the above solution

.forward

1 Like

in my root there is no .forward or in the etc or in any of the domain dir in the etc
should i just make one? then what should i do with it? or what should i read to know what i can do with it?

I know i said i am not looking for a solution, still true, but i could use a little more insight as i am newb to this world.

Thanks again for all your help thus far

Try looking for /etc/mail/aliases
create a line that looks like:

remember that myprocess had to process all the lines of the email including the header records.
I like to keep the email in the recipient mailbox as well so that the original email is still available if debugging is required.
run 'newaliases' after editing the file.

In many implementations, if properly configured, and the local security model allows, a .forward file in your home dir can contain '|command_string', in which case every email coming in gets processed by that command, potentially parallel instances for multiple messages, so be careful what you script.

If this is not acceptable, you have to poll the email file or mail commands, unless you shut down the normal mail server, and your web server also listens on port 25 as smtp/esmtp email server. It could send any unrecognized email to another email server/host to deliver, or file it. SMTP/ESMTP is a pretty easy protocol; just Google for RFC SMTP or RFC ESMTP and find the nice wikis and such. You can also look at raw email messages to see examples of how messages are formatted, in case you want to forward them via email (by tcp connection to port 25 on a different host, as you are now the entire local email service).

Most systems permit the .forward file by default. You should not need "polling" or anything more complex than a single entry in the .forward file.

Just test it and see if it works! It should, if you have it configured properly.

If you do a Google search on SMTP mail and the .forward file, you will see that this is normally enabled, by default.

Just watch out for the security audit! My last Solaris system had it turned off. The .forward wiht pipe is one "non-polled" solution, but to scale up with lower overhead, taking over port 25 saves all the fork and exec overhead. Of course, in the end, the port socket fd will be "polled" by poll or select unless it gets its own thread! It turns out there is often a layer of polling even in interrupt-related mechanisms, sometimes in the kernel! After all, what we call UNIX is mostly what UNIX calls Time-Sharing! :smiley:

Well, it is a bit premature to discuss 'security audits' when:

  • You don't know even if it works.
  • You have no idea what their organizational security policy is.
  • You have no idea even if they have security policies (LOL).
  • You have no idea what is the purpose of the server or this application.
  • You have no idea what the risk model is for the organization.
  • You have no idea what is the risk model for anything in the poster's world.

One the things that is very important here at The UNIX and Linux Forums is to not make a bunch of assumptions that may or may not apply to others.

In fact, upon review, the OP said:

So all he needs to do it try it by editing the .forward file and trying to forward to another email address.

Technically unacceptable is somehow worse than Politically unacceptable? Many milieu are very security concsious, and more are getting more so every day; many nice features are being turned off, so the wise user includes the local security culture in their tool choice process. Everyone should have at least a virtual seat at the design table: Security, Testing, Admin, Production Support, Configuration Management, Legal, all levels of Users as well as Management and Development.

Of course, if we had better requirements . . . . They say even a very dumb engineer can design and implement from good requirements, but writing good requirements takes a very good engineer.

I have no idea what you are talking about, DGPickett (Sorry). This does not need to turn into a political discussion. The poster asked a very simple question.

Using .forward in a users own directory on a shared server (where they are not a privileged user) is not a giant security hole that is such a high risk.

Let's keep this conversation on track and don't create a bunch of "security requirements" and "risk" that don't exist.

The question has been answered. Time to move on.

I do not set the security requirements, I just design in harmony with them.

Someone hates that .forward pipe, and once it is maligned, managers will start turning it off as part of a comprehensive security audit remediation.

I guess you are in "last word I fixed it" mode, not "ask the user if they are fixed yet" mode. Customer focus is not at political discussion. It is good design.

I design based on risk, and I have been in infosec all my very long career.

This is nothing wrong with having a .forward file in the situation posted by the original poster, IMHO.

There is no risks identified, there are no vulnerabilities identified, there are no threats identified.

I have been in infosec all my very long UNIX and Linux career, and have a CISSP, yadda, yadda, yadda... Security is based on risk, not speculation.

One of my biggest "pet peeves" are people who make blanket "this is not good" statements in the absence of any risk analysis. This is the biggest mistake many technical people make in IT security.

If you are going to make "sweeping statements" about "this is good" and "this is not good" here, you need to be prepared to completely back it up, technically, since I run the forums, LOL... You are not going to "beat me into submission, I assure you" :smiley:

There is no technical argument (that you have made) where in a low risk situation on a shared server with an unprivileged user that a .forward file is such a high risk.

If you are willing to stop "hand waving" and provide technical facts on what the vulnerability, threat and risk of this original posters application, I'm all ears :smiley:

Otherwise, move on. Thanks.

---------- Post updated at 17:27 ---------- Previous update was at 17:24 ----------

Note:

I did a Google search on these terms:

...and after looking at around 8 pages, found nothing interesting.

Might be dated (14 years seems long but my local OS seems to be 1997 era) or inapplicable, but you know how managers can be:

CERT Advisory CA-1996-20 Sendmail Vulnerabilities

It's dated..... nearly 15 years old.

To me, it seems you are playing the role of "bureaucratic manager" because you are really grasping at straws to pull up a 15 year old vulnerability in sendmail to try to make a point.

Please don't pull up 15 year old vulnerabilities to make points based on sendmail releases that have not been installed for over a decade.

Thanks.

Should I close this thread before it further degenerates into a pointless debate with on purpose only to debate a point that has irrelevant to the original posters question?

Frankly, I am inclined to do so.... because these are not the "debate moot and irrelevant points endlessly forums", LOL.

---------- Post updated at 19:50 ---------- Previous update was at 19:45 ----------

Heck, based on your logic, we need to shut down the Internet, LOL. Think of all the Apache, PHP, MySQL, Linux bugs in the last 15 years.

Better not run Linux! No MySQL !! No PHP either, there was a bug a few months ago! No NT, don't run Windows either. Better not run Solaris, AIX.... !! Better turn them all off !! All of these systems have had vulnerabilities, and most a lot sooner than 15 years ago!

I'm closing this thread.