I suspect many of you – like SitePoint – use PHP to process inbound email for various purposes. For example, our warehousing / fulfillment company sends us an email with an XML attachment notifying us when an order has been shipped. It includes various useful details (shipping times, tracking numbers, freight costs, etc) that we need to store in our database.
I’ve hit problems in the past trying to shoehorn this behavior into our vpopmail installation. Vpopmail is a handy set of patches for qmail that ease the handling of large numbers of email domains and users.
The key problem is, vpopmail generally runs as the “vpopmail” user, and delivers all mail while executing under this UID. Hence any scripts it invokes do not have permission to access the PHP libraries that make our applications tick.
A lot of Googleing led me no-where, other than the questionable option of making all our PHP libraries world-readable. No thanks!
I discovered that our best bet was to create a local domain to have the relevant emails delivered to. In a vpopmail installation, local domains behave just like regular qmail domains rather than vpopmail’s “virtual domain” approach.
e.g someuser@yourlocal.domain.com
where “processing.sitepoint.com” is setup as a local domain.
Setting up a local domain is simple; just add it to /var/qmail/control/locals (and don’t forget to put it in rcpthosts, too). Then -HUP qmail-send and you’re good to go.
Once this is done, emails to someuser@yourlocal.domain.com are delivered to the UNIX system account “someuser”. And most importantly it is delivered under that users’ UID/GID.
Thus the script that processes these emails now executes as “someuser” which presumably has access the relevant libraries, and can get the job done.
Jules Szemere
