Automatic email acknowledgement using extracted email address.
Client is a small business using gmail.
Client receives emails from a screening source that forwards an email address for a prospect (located in what appears to be a table).
Client wants to automatically send an acknowledgement email to the prospect - presumably using their gmail account which is web-accessed.
If I try to do this then it won't be very efficient and I may miss something that's available.
As I see it:
- maybe gmail offers something that would be useful.
or
- parse the email body for the prospect's email address. This may be easy since the entry is in a table. I've done this with Excel in similar situations.
- launch a template email using the address found. I've not done this.
What would you suggest doing to address this requirement?
Use some tools that I'm unaware of?
Hire someone?
Client receives emails from a screening source that forwards an email address for a prospect (located in what appears to be a table).
Client wants to automatically send an acknowledgement email to the prospect - presumably using their gmail account which is web-accessed.
If I try to do this then it won't be very efficient and I may miss something that's available.
As I see it:
- maybe gmail offers something that would be useful.
or
- parse the email body for the prospect's email address. This may be easy since the entry is in a table. I've done this with Excel in similar situations.
- launch a template email using the address found. I've not done this.
What would you suggest doing to address this requirement?
Use some tools that I'm unaware of?
Hire someone?
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
There's not a Linux server available or going to be.
I've done the parsing for stock prices, etc. using Excel. Maybe that would work for the email addresses.
Next would be sending email out from Excel. Seems like a doable thing. But, it will require a resident email client program I suppose.
I've done the parsing for stock prices, etc. using Excel. Maybe that would work for the email addresses.
Next would be sending email out from Excel. Seems like a doable thing. But, it will require a resident email client program I suppose.
You don't need a Linux server. You only need some type of "server" to run the script, check the mailbox, and send out email. Your suggestion of using Excel is essentially the same, just replacing the app to do this with another app which does this not quite as well.
ASKER
OK. So here is how I might paraphrase Steve Bink's suggestions in a context that's familiar to me:
1) Setup a gmail filter rule to match the messages to which an auto response will be generated.
2) gmail filter rule will forward these messages to an email address which is monitored by an email client like Outlook or Thunderbird.
***Then a small miracle occurs*** Any ideas here?
3) Client filter rule will respond to these messages using a Template.
Well, it's not much of a miracle but somehow the incoming messages have to be parsed to extract the included email address and that address used in the To: line for the Template.
1) Setup a gmail filter rule to match the messages to which an auto response will be generated.
2) gmail filter rule will forward these messages to an email address which is monitored by an email client like Outlook or Thunderbird.
***Then a small miracle occurs*** Any ideas here?
3) Client filter rule will respond to these messages using a Template.
Well, it's not much of a miracle but somehow the incoming messages have to be parsed to extract the included email address and that address used in the To: line for the Template.
Your first step is fine. The second step should remove "an email client like Outlook or Thunderbird", in favor of "a PHP script designed to poll the mailbox".
The missing miracle (what I call "voodoo") is the hard part. Email structures, while somewhat standardized, still have a wide variety of formats which make the job less than straight-forward. Your inbound email could be coming from a variety of clients, all of which can format the envelope and contents in different ways. You will need complicated logic to help find the actual wheat in the chaff.
Before I start this, I'd like to remind you that the code to which I'm directing you is part of a much larger application (heavily customized CiviCRM). This will help point out the overall idea, but will need some serious adaptation to work for you as a stand-alone worker.
As I mentioned, our organization receives email from a ton of different sources. All of these are scanned by a human for validity. Valid emails are forwarded into a private mailbox. Our work starts by polling that mailbox using this PHP script. Line 314 begins our interaction with the IMAP mailboxes. Line 317 attempts to instantiate our custom IMAP session object. On line 380, we begin the actual polling of the box. The first step is get a count of new messages. The loop beginning at line 384 cycles through those messages, instantiating a custom IMAP message obejct for each one.
That message object is the overall workhorse of this process. It is essentially a wrapper around the imap_* commands found in PHP's library. We've added additional functions to do specific work, such as parse through email headers, discover the internal envelope in a forwarded message, and use regex-based scraping to get a best-guess discovery of data we want.
After each message is processed, we're storing the results in our database pending human review. I should point out that as complex and as thorough as our code is, we still don't trust it enough to completely automate. This is due to the incredible variety of structures found in email in the wild. We just can't say with any certainty that an automated parsing of an email is going to pull exactly the information that we want.
Once all the dust clears, you should be left with the un-encoded email content, its meta-data, and (assuming you use the highlighting features we added) some best-guess notations regarding the original recipient, forwarder, etc. The last step would be to generate a new email based on that information. Sending email is much easier than reading it, and would be a quick addition to the end of this process.
Obviously, this is not a turn-key solution. I'm sure you have a lot of questions at this point. I'll try to clarify where I can, but you should know that adapting this is a mid-sized project in itself. If you're not prepared to deal with code at this level, you should probably stop here and find someone who is.
The missing miracle (what I call "voodoo") is the hard part. Email structures, while somewhat standardized, still have a wide variety of formats which make the job less than straight-forward. Your inbound email could be coming from a variety of clients, all of which can format the envelope and contents in different ways. You will need complicated logic to help find the actual wheat in the chaff.
Before I start this, I'd like to remind you that the code to which I'm directing you is part of a much larger application (heavily customized CiviCRM). This will help point out the overall idea, but will need some serious adaptation to work for you as a stand-alone worker.
As I mentioned, our organization receives email from a ton of different sources. All of these are scanned by a human for validity. Valid emails are forwarded into a private mailbox. Our work starts by polling that mailbox using this PHP script. Line 314 begins our interaction with the IMAP mailboxes. Line 317 attempts to instantiate our custom IMAP session object. On line 380, we begin the actual polling of the box. The first step is get a count of new messages. The loop beginning at line 384 cycles through those messages, instantiating a custom IMAP message obejct for each one.
That message object is the overall workhorse of this process. It is essentially a wrapper around the imap_* commands found in PHP's library. We've added additional functions to do specific work, such as parse through email headers, discover the internal envelope in a forwarded message, and use regex-based scraping to get a best-guess discovery of data we want.
After each message is processed, we're storing the results in our database pending human review. I should point out that as complex and as thorough as our code is, we still don't trust it enough to completely automate. This is due to the incredible variety of structures found in email in the wild. We just can't say with any certainty that an automated parsing of an email is going to pull exactly the information that we want.
Once all the dust clears, you should be left with the un-encoded email content, its meta-data, and (assuming you use the highlighting features we added) some best-guess notations regarding the original recipient, forwarder, etc. The last step would be to generate a new email based on that information. Sending email is much easier than reading it, and would be a quick addition to the end of this process.
Obviously, this is not a turn-key solution. I'm sure you have a lot of questions at this point. I'll try to clarify where I can, but you should know that adapting this is a mid-sized project in itself. If you're not prepared to deal with code at this level, you should probably stop here and find someone who is.
ASKER
Ah! Please note in the original question:
"Located in what appears to be a table"
So, I should think, no worries about varying email formats:
One sender
One table
One email address entry
Also:
Probably very low volume.
"Located in what appears to be a table"
So, I should think, no worries about varying email formats:
One sender
One table
One email address entry
Also:
Probably very low volume.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Thanks all!
Internally, we have an application which periodically polls the private mailbox for new mail. When it finds one, it attempts to parse the email to get past the outer headers created by the most recent forwarding. Once the outer envelope is removed, the process attempts to identify the original sender, content, and other relevant headers. Finally, the discovered information is displayed in a UI for final processing by a staff member.
All of our mailboxes are standard IMAP/POP, and the internal processor is a custom PHP script developed by our team. It was actually developed in the form of an extension for CiviCRM, but could probably be easily modified for stand-alone operation on any arbitrary mailbox. After modifying the script for your environment, the only other requirement would be a local mail service (such as the default postfix, et al) to send your auto-responses.