NYCPHP Meetup

[Mark Armendariz]

I'd worked on a similar app a few years ago for a customer service
application.  I've been wanting to re-implement it for my own projects,
though time's been lacking.

Basically, the best way I could figure was to use the email addresses as
your filters.

Set up a database of jobs.  Each job has a begin date and end date.  Each
job also has a list of the email addresses of those involved in the job.

Forward all the emails to a php script (or perl or whatever, I used php).

Now, the script will look at all email addresses in the message (to, from,
cc, etc), check them against the jobs db.  If the address matches an address
associated with a job and has been sent between the beginning and end dates
of said job, it should be so associated.

Then mark / filter / process your messages from there, whether it be adding
tracking info to the subject / message body for client-side filtering or
forwarding it / storing it in the database, etc.

Also, have a cache of unrecognized email addresses in case some haven't been
associated with a job and should have.

A tagging system might work better (rather than 'folder' organization) as
there's times when email messages or address might be associated with
multiple jobs.  

Good luck!

Mark

> -----Original Message-----
> From: talk-bounces at lists.nyphp.org 
> [mailto:talk-bounces at lists.nyphp.org] On Behalf Of Andrew Yochum
> Sent: Friday, January 13, 2006 11:28 AM
> To: NYPHP Talk
> Subject: Re: [nycphp-talk] An Email Architecture Puzzle
> 
> On Fri, Jan 13, 2006 at 02:18:07PM -0500, Kenneth Downs wrote:
> > OK, here's a brain teaser.  I've got my own answer in mind 
> for this, 
> > but I'd be really curious to see if anyone else has any ideas.
> > 
> > The problem is simple:  All emails flowing through a certain domain 
> > must be tracked and associated with a job in a database.  The 
> > following rules
> > apply:
> > 
> > 1) Must not require re-inventing an SMTP server, or any C 
> coding in an 
> > existing SMTP server.  By the same token we don't want to re-invent 
> > webmail and force everyone to use it.  Solution must be in 
> pure PHP, 
> > though may use any plug-in or extension system that an SMTP server 
> > provides that allows coding in PHP.
> > 
> > 2) Must require minimal if not zero change in habits for 
> users.  For 
> > instace, requiring users to put complicated codes into their emails 
> > won't work because people won't do it.
> > 
> > 3) Some kind of pool of un-matchable emails should be 
> available to an 
> > admin who then matches them to jobs.
> > 
> > 4) Every email should slot into a job, and replies should 
> be sortable 
> > into threads by UI software.
> > 
> > So how would you do that?
> 
> Configure your SMTP server or procmail to filter all email 
> through a PHP script.  Parse, munge (like adding a tracking 
> number to the subject), store it in your DB & pass it through 
> to the recipient.  This is much the same way many spam 
> filters and email-based help desk apps work...
> and CLEW.
> 
> HTH,
> Andrew
> 
> 
> --
> Andrew Yochum
> Plexpod
> andrew at plexpod.com
> 718-360-0879
> _______________________________________________
> New York PHP Talk Mailing List
> AMP Technology
> Supporting Apache, MySQL and PHP
> http://lists.nyphp.org/mailman/listinfo/talk
> http://www.nyphp.org
>