I need to process an email inbox, monitor it for messages with a particular subject line. If it finds a match I need to get the body content, manipulate, and insert into a database. Ideally would mark the message as read and move it to another IMAP folder as well.
I'm poking around PHP documentation imap_open (http://us2.php.net/imap_open) and found a link http://www.linuxscope.net/articles/mailAttachmentsPHP.html#_jmp0_
Before I get too far, I'm wondering if anyone is aware of an existing PHP class that's a good wrapper for the basics I'm looking for:
IMAP:
connect
list folders
list messages
read messages - from, to, subject, body
move messages to server folders
read/unread status
Thank you!
I've not used it for anything but sending mail, but it appears that the Zend_Mail component will get you at least most of the way there. It doesn't seem to support moving messages on the server, but you could probably extend it fairly simply.
I've tried Zend_Mail for IMAP and have some highs and lows. I could connect and read, move emails but it is quite buggy. You can check for subject or sender, parse headers, reach attachment by parsing different parts.
Zend_Mail_Protocol_Imap is not using any of the PHP imap/ext function. (Why?) Reading folders with thousands of emails is slow. The internal order of a folder is not actually chronological, which is so strange. Probably depends on how the storage was implemented (I parsed a google.pro account). Sometimes the connection closes unexpectedly and debugging it is quite heavy.
There is also a Pear_IMAPv2, which is beta and I could not even succeed in installing. The alternative will be to install imap/ext and do everything by yourself.
Good luck.
Related
Is there any tutorials out on the web that would show how to setup a program that would use piping, PHP and MySQL to setup email where replies would be sent into the database, or something similar to this?
Thank you in advance for any direction in finding out more about this.
PHP and MySQL are both mutually exclusive, and even more so from an email server.
To use PHP to receive email and insert it to a MySQL Database, you would have to write PHP code that is going to connect to a POP3/IMAP box and receive email directly and read new emails, subsequently inserting them into the database for handling them as you wish.
Luckily for you there are a whole host of mail related extensions for PHP. Note that you will specifically want to look at the set of imap_* methods (despite the name, they also work for POP3, etc).
I know, you could write your own SMTP server in PHP but who on earth wants to do that?
You can write own script which will check (via IMAP or POP3) for new e-mails in e-mail box and will store some e-mails directly into database.
Writing PHP CLI scripts is easy but there are some differencies between operation systems. See http://www.php.net/manual/en/features.commandline.introduction.php
The script can be periodically triggered via CRON or any other similar mechanism.
In relation to an earlier question I'm looking for an alternative way to send an order from my website to the division in my company that processes the order.
Currently I use PHP mail(), but frequently this gives problems. Big delays occur. Are there alternatives to PHP mail() that pushes the order to my company? So I prefer not to poll the website.
mail() is fine for simple stuff, but often you want a more robust library that has solved the mail problem in PHP.
My personal choice is Swift Mailer.
Also from reading your other question, could this be of benefit
Your app writes the order email to database, in a queue.
You have a Cron running, that sends say 30 emails every 10 minutes.
It then removes the last sent 30, ready to be processed again in 10 minutes.
The advantage is that when you have a queue of emails to be sent out, they can be processed in batches, and also you will have a copy in the database if the mail fails. It will be easier to query the database then chase up the mailed that was undelivered (or delivered late).
Currently I use PHP mail(), but frequently this gives problems.
I'll bet you a lot of money it does NOT frequently give problems.
I have never come across problems in PHP's mail function. I have seen problems with bad php.ini settings for mail, and a host of problems with the programs which process mail after it has left PHP. Your use of the word "frequently" implies that it works some of the time, so, in the absence of frequent updates to php.ini, the problems are all on your mail handling infrastructure.
Indeed - I would recommend you go have a look at the PHP bug list - there will be lots of reports about problems getting mail from scripts to users inboxes - but none of them will be due to a failure of the PHP code.
So if the problem is elsewhere, using a replacement SMTP client will have no effect whatsoever (unless you configure it to bypass the bad MTA).
Understanding how email works, and why it fails, is far from trivial. When you add in to the mix, the lengths some people go to (usually undocumented) to prevent spam, it starts to become very complicated. Even if you had given precise details of your infrastructure and configuration, it would be difficult to even hazard a guess as to where why and how it is failing.
Certainly, you need to start by looking at your email logs and headers and checking your MTA and MUA configurations to start to resolve the problem.
C.
There is inherent insecurity in using SMTP to transmit orders. Not to mention the delays caused by all the routing, spam-checking, etc. that is caused by using the mail server. Are you sure you need to email the order? Wouldn't something more along the lines of a server-to-server HTTP transfer, perhaps XML-based, be a better option?
You could use a second server in the processing division that would receive the order from your web server via a protected (firewalled) connection that would process the order, in this case making it available to the person in the order processing division who reads and deals with the order.
My company has a website built with PHP. We use the built-in PHP email functionality to send thousands of emails to subscribers on a daily basis.
This is a terrible idea. It chokes out our server, and takes hours to complete the whole batch.
Now I've looked at mass mailing services like MailChimp (which would replace our current system of sending the same email to many people), but what I think I'd really like to do is to set up a somewhat-sophisticated notification system.
Rather than send a mass email to each person each time something important happens, I'd like clients to be able to customize the rate and content of the emails that they receive.
Even using this new idea, we're talking about A LOT of emails being sent.
So my question is very specific: I have a rough idea of how to build the system internally, but what is the best way to send out all of these emails?
Bullet points to consider:
Sometimes emails' contents are identical across recipients, but many of them will be customized per-user (they choose what they get notified about, and sometimes it is aggregated).
I want a system that is not going to choke the server, and will complete in a decent amount of time. I don't mind going with a third-party service (even a paid one) if that is what it is going to take.
The system should hook into PHP easily, or the API or whatever should be relatively easy for me to call from your typical web server.
We have a dedicated server and full control over it (so we can install apps, services, whatever).
Any kind of detailed tracking information (opens, clicks, etc) is a huge plus.
These emails are sometimes time-sensitive (so can't take all day to send).
Thoughts? Tips? Point me in the right direction?
EDIT
To clarify:
I can do these on my own:
maintain user list
handle email content generation based on user preferences
And need something else (app, third-party service, w/e) to:
accept email content and addresses and actually send the emails out
provide tracking data (opens, clicks, etc). The more detail the better.
I'm leaning towards a third-party service, since I'm not sure any app can avoid choking the server when sending thousands of emails (though I wouldn't consider myself an email expert so I could be wrong).
We use the built-in PHP email functionality to send thousands of emails to subscribers on a daily basis.
This is a terrible idea. It chokes out our server, and takes hours to complete the whole batch.
Why do you think that your problems are anything to do with the built-in PHP email function? It's a very thin wrapper around 'mail' or a simple SMTP client depending on what platform you are running on.
When you say it chokes your server - do you mean your email server? Your web server? something else?
There's nowhere near enough information here to make a proper diagnosis but it looks like the problems are of your own making - sure, there are lots of people out there who promise to sort all your problems for you if only you buy their latest product/service. But there's a very good chance that this isn't going to solve your current problems.
Can you tell us:
what OS the PHP is running on
how you invoke the code to create the emails
what the mail config in the php.ini file is
what type of MTA are you using? On what OS?
how is youe MTA copnfigured - does it deliver directly or via a smart relay?
which server is getting "choked"?
What anti-spam measures do you have in place for outgoing mail?
Then tell us what you've done to diagnose the fault and why you think its specifically on sending mails.
C.
I'd recommend using the third party mailing service Silverpop, or something like it. We've used them for a few years and have been fairly satisfied. They already have relationships with the major email clients (AOL, Yahoo!, Gmail, etc.) and they do a good job of telling you if the stuff you're sending is likely to be classified as SPAM.
They have a fairly extensive API that uses XML HTTP/HTTPS requests that can tie in to existing systems. You can use it to remotely trigger emails, schedule mailings, customize email contents, set up, manage and query huge lists of recipients, run batch processes, etc.
It isn't a perfect service, but compared to a lot of others out there, they do pretty well. I have had very few complaints about them thus far.
I usually got around this by having a mail "sending" function that dumped the emails into a queue (database table) with a job that ran every couple of minutes, grabbed the next x emails in the queue, sent those out and marked them as succeeded. That's the simple bones of it. You can then add on handling for email failures, returned mail, etc in version 2.
Use Google AppEngine if you are worried about scalability & customization: it provides an email API and you can interface anything to it provided it is through an HTTP interface.
Of course, this is just a suggestion - disregard if this doesn't fit.
Quite possibly not ideal, but if you're looking at large scale transmission there are commercial solutions such as Port 25's PowerMTA that can be set up to effectively transmit the contents of a given folder.
As such, you'd simply use PHP to create the personalised MIME formatted raw data for each outbound email and place these in a temporary directory prior to transmission. (I've written such a system in the past and you'd be surprised at the PHP's ability to grind out the emails, even with quite complex text & HTML emails with images as inline-attachments, etc.) Once you were ready to transmit, you'd then move the files en-masse to the PowerMTA monitored folder and it would take care of the transmission.
Depending on how you look at it the benefit/problem with such a solution is that you'll need to build trust relationships with people such as AOL, MSN/Hotmail, etc. to ensure that your mail server isn't blacklisted due to user's reporting email as SPAM. (That said, this will likely be a factor with any DIY solution.)
Why not keep your PHP system and use a third party SMTP service? Some reliable companies offer the use of e-mailing-only machines at reasonable prices, e.g. Dewahost who I am planning to use.
Also see the question Third Party Email Senders and my answer there.
Check out Campaign Enterprise for a possible in-house solution.
One of my friend uses http://www.tailoredmail.com but i havn't used it personally
I know this is an older question, but I just wanted to suggest SendGrid which is essentially an "Email Server as a Service" allowing you to send emails with cost per email.
I want to send data to an emailaddress and save it into a MySQL database (PHP).
What is the easiest way to do this? (no form post, no curl etc., just email)
there are a few ways.
use a postfix alias script, basically, postfix receives your mail, and then runs it through a script of your choosing. The contents of the mail appear in STDIN - then you can do as you please with the contents of the mail.
Use a custom mail server like apache james, that is designed to process mail, and 'do something with it'
{A good one I found recently was in the google labs - http://freshmeat.net/projects/subethasmtp} - looked really good.
pls bear in mind that email is not a guaranteed protocol, if you are trying to do app-to-app messaging, then there are probably better ways!
Hope this helps., ace
If your server doesn't have imap but you have an outside system which does have cron you can write a page that checks the email account and loads the data into MySQL then set up a script on a machine that does have cron to wget the mysql page once every X minutes where X is how frequently you want to load data.
Alternately if you know the emails will load quickly you can set up small one field table in your DB with a time stamp. Each time your PHP script runs it checks the time stamp and if it's more than 5 minutes old it calls the email loading script before loading the web page.
If you can access the email using POP just have a process checking the email with POP functions and sending everything to your database
Also you could use php IMAP support
Assuming you know how to save the data to mysql already, you will need access to a mail server, either your own, a webhosts, or you could use a free one such as Gmail, or Hotmail.
You can then use PHP's IMAP functions (which can access POP too) to access the mail. Articles which may help you with this: PHP imap info and a tutorial on creating PHP webmail
There is a slicehost step-by-step tutorial that takes a unix based machine, installs postfix on it, sets it up to use MySQL and configures it to accept virtual users and serve/receive email from multiple domains.
The set up is clean, fast and secure. Life is good, eh?
http://articles.slicehost.com/email
Perhaps you should look at www.dbmail.org
1) How can a linux server be configured such that it can receive any emails sent to account#domain.com.
2) How can these emails be accessed and displayed by a PHP script?
I'm building a simple web mail script, so i want to receive emails only for the registered email accounts and classify their emails and show them.
Needs also to have the ability to show attachments.
Honestly, you're better off looking at one of the webmail systems already out there and modifying it to fit your needs rather than writing something from scratch.
The email RFCs are a fun read (no, no they're not) and attachment handling has caused many developers to take up heavy drinking. Don't get me wrong, it can be done. Its just a lot of work and not something that you want to take on unless you have a bunch of time to dig deep into it.
However, if you wanted to write something quick and simple, I suggest setting up a linux box with an Imap or pop server and then accessing that mailbox with the appropriate PHP / Pear libraries. That will be the quickest way to get going.
But I would still recommend using one of the off the shelf solutions that are out there and hacking it up to fit your needs.
The mail server itself can be setup to receive email with any number of MTA's (sendmail, postfix, exim, etc). You'll want SPAM protection and Virus scanning as well (again there are free packages in any distribution for this). Be warned, running your own mail server is NOT a job for the faint of heart these days.
Once that's in place I would probably setup IMAP and use PHP's IMAP functions to retrieve and parse the messages. Viewing attachments will be a lot harder if you want them readable in the browser, but easy to mark that they are there and make them downloadable.
There is likely a class already written that does most of this for you (excepting the setup of course).
Update: In fact there is an old article at evolt that appears to cover this.
You have a lot of work in front of you - don't expect someone to just post some code here.
Start by reading the POP3, SMTP, and IMAP RFCs. Then go find a commercial/open source solution.