Ask YC: How do I send incoming email to a PHP script? | Hacker News Reader

Ask YC: How do I send incoming email to a PHP script?

23 pointsbreck16 comments

I've never dealt with email servers so don't quite know where to begin. All I'm looking to do is send incoming emails to a PHP script that can then parse the message and take action based on the contents. I've got a box running FC and it looks like the default mail server is postfix. Is there a simple way to get this going? I'm worried about fiddling too much on my own as the server hosts a few dozen moderate traffic sites. Thanks!

View on HN

In the postfix configuration, enable allow_mail_to_commands ( http://www.postfix.org/postconf.5.html ). In a Unix account home directory, create a .forward file which begins with a pipe symbol and names your script: |./my_mail_stub.php

For each message sent to the account, postfix will run your script. Your script can obtain the raw message from stdin.

You'll be pleased to know that the principle for sendmail and qmail configuration is broadly similar and shouldn't require any changes to your script.

Thanks a bunch. Just about got it working.

If you're running a pop3d or imapd - then it's much better (and safer) to have your script fetch email from there.

Check: http://us3.php.net/imap

If you're not running a pop3d or an imapd - then xirium's way is good - just get postfix to forward to a mail account that runs the script from .forward.

Note: Someone could mailbomb the account with the .forward file and cause your script to be invoked every single time a mail comes in (hence, a little less secure!)

A mailbomb in an IMAP box would still be a cause for concern. It could mean that incoming mail doesn't get processed for hours or days--if the system relies on timely information (like in a support ticket tracker) this could potentially be a big problem.

procmail would allow one to pre-process mail and add some rules to prevent dupes and not even forward messages that don't make sense. For example, if you're expecting to receive a ticket ID in the subject and there isn't one, you toss the message rather than forward it. If you get multiple messages with identical contents, you can also toss it. procmail has built-in tests for this sort of thing. A milter or filter could be written to do the same job, but that would apply to all incoming messages unless you jumped through a few hoops and made it pretty smart.

But, a mailbomb would still be a concern just from a raw mail processing speed standpoint. But, Postfix can throttle SMTP servers that are sending faster than a certain rate...so it can be locked down, but you have to address the problems at multiple layers.

That said, any of the solutions given will probably work fine--most of the time the usual spam and AV filtering tools will keep your mail clean enough to just do the simplest thing and fix it if it breaks (possibly by going to more complex solutions).

You could also use a cron job (php script even) which can fetch emails and do what ever with them accordingly at what ever interval you need.

That's a cunning plan. Your script could connect to a POP or IMAP server. That would allow it to process an unlimited number of messages in one run. This would be more scalable because you could do stuff like database bulk inserts of data from many messages.

It would be more awkward to write and more awkward to test but it would definitely be worthwhile for a high volume of messages.

works great if it doesn't need to be real time...

There's a chapter about this in Cal Henderson's Building Scalable Websites...

yes, awesome book

procmail will do the job. From the homepage:

"Procmail can be used to [...] preprocess your mail, start any programs upon mail arrival [...]."

http://www.procmail.org/

We also use procmail for this sort of thing (along with a lot of other things, like spam and AV filtering, advanced delivery logging, etc.). It's a bit of a learning curve, but once scaled, is a very powerful tool. It also has the benefit that it can be a dispatch table, of sorts, and call different scripts based on different contents or subjects or whatever, and provides logging and other stuff reasonably cheaply. And, it provides security via its DROPPRIVS directive. Yep, procmail is a good choice.

I use sendmail to pipe incoming messages to a python script using smrsh. "sendmail restricted shell" one liner change to sendmail.conf. Google around, lots of examples.

There's probably something prebuilt already (dunno) but writing your own POP client isn't very difficult. Figure out how to set up a socket connection and issue some commands (look these up, but from memory all there is to POP is LOGIN, PASSWORD, LIST, RETRIEVE and DELETE). Now POP server processes were fairly CPU hungry (but short lived as well, so it wasn't too much of a problem) back in the day of 400MHz servers but nowadays you should be fine.

Ah yes, the PHP way. Instead of getting a library that does POP, just hack together a half-working implementation that may or may not randomly lose data. Good plan.

knee-jerk, much?

Oh come on. This is POP we're talking about, not a full fledged SOAP client. Writing your own POP client is easier and takes less time than scavenging the internet for someone else's, looking through it to see if it doesn't have bugs and testing it.

In fact, I'd argue that if you've never written any sort of network client code, writing a POP client is perfect to get you started. It's just that simple.

Reply on news.ycombinator.com