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).
Comments
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).