I would like to implement an email receiving feature similar to the one found at asana.com:
http://asana.com/guide/tags-email/email-incoming
Users can send email to a designated address, and the system will perform actions based on recipient and message contents.
Any recommendations for libraries that handle this?
I see openpop.net, but i wonder if this technology would have a delay since by nature pop doesn't receive mail on its own, you must initiate the request.
Anyway, hoping to get the scoop on this technology from the experts here. Preferably, an answer would direct me to both a library and some tutorial/documentation.
If you're doing this on a Linux box, it's fairly straight-forward to set it up such that incoming emails are piped directly to a script - be it PHP, PERL, etc. See http://harrybailey.com/2009/02/send-or-pipe-an-email-to-a-php-script/ for an excellent article.
Related
Is there any extendable mail server that can implement a service like a chat robot?
I think what I am looking for is a middleware based on SMTP.
Most unix MTAs can do that. One way is to make a login called foo so that you have an email address foo#example.org. Then you put |/home/foo/program into /home/foo/.forward. Now /home/foo/program will be invoked on each incoming mail, receiving the message content as input.
There's a program called formail which may be quite handy (if you write in sh).
I found this library and it provides exactly what I need.
https://code.google.com/p/subethasmtp/
I am creating a PHP system that will forward emails, (ie. someone#emailforprofession.com to someone#gmail.com) without using an SMTP server which is faster and more stable? PEAR::Mail or PHP: Mail? (or another one entirely)
I would be using extra headers and attachments but mainly trying to keep it looking and acting the same. (if anyone has an example for forwarding with attachments PLEASE provide it!)
And not exactly on the side but is there a way for people to be able to send email from they're someone#emailforprofession.com email address without having a complete inbox etc?
It would probably be better for me to use a real email provider but these are supposed to be free email addresses so paying by the email address is not an option, if anyone knows of a service that: charges by the month or year, has an API that email addresses can be created from and that can set up email forwards via the API that would be most appreciated.
I currently have a partial system together but would like to know which way I should go first.
Thank you all.
The PEAR class supports multiple mailer backends, which allows you to
switch whenever needed and you'll be able to perform some benchmarks
and see which backend suits you best. The native mail function on the
other hand is much less advanced and will show a clear difference in
performance, especially for that amount of mails.
I also suggest you have a look at PEAR's mail queue class:
http://pear.php.net/package/Mail_Queue
This is much more recommended for larger projects such as yours,
you'll also be able to implement a cron like feature which will send a
certain amount of mail per period you choose.
Here
Recently i decided to build this kind of web application. But i have got no experience for this.
So, to begin with,
Are those system using SMTP function and include those mail plugin such as PHPmailer??
Thanks
You have two options at your disposal.
Roll your own SMTP server + use a pre-built library relevant to your language/framework (PHPmailer)
Purchase the services of an email service provider
If you want to go with the second, you are giving up direct control so that you won't have to maintain an SMTP server, the emails will get into inboxes without question, and you'll get detailed statistics about what you are sending and what people are doing with it.
With the second option, you have two types: transactional and bulk.
Transactional Mail Providers:
PostageApp
Sendgrid
PostmarkApp
Bulk Mail Providers:
MailChimp
AWeber
Exact Target
Constant Contact
Take a look at your service and determine what sort of mail you will be sending (most likely bulk) and pick your provider based on the features you will be needing.
The correct answer is "propably", since you can't know about all systems. The easiest way to get answer is to look at similar OSS projects source code.
What's the easiest way to process incoming email? Our objective is to get email into a Resque queue. We've explored and integrated a lot of options, like piping email through Postfix into Ruby (which turned out to be unreliable), piping email through Google App Engine back to our server (which turned out to be shaky), and using Sendgrid (which is expensive.)
I'm trying to explore other ways to get email processed. Any ideas?
If the email is received and hosted by an IMAP-capable server (Gmail is good enough), then the messages can be retrieved and processed once and again from almost any programming language using standard libraries.
My university refused to allow us to access out mail via POP or IMAP etc so I want to write a GTK based C app that sits in my notifcation area and does the job of a mail client notifier. Because I can't use anything like POP or IMAP, what would be a good way to do it? I guess I could scrape the HTML and look for a tag that is only present in unread mail or something?
Any Ideas?
I know you said C/GTK but it's a piece of cake in Python/GTK with urllib2, libcookie, and BeautifulSoup. That way you don't have to deal with raw sockets, and parsing the HTML yourself. Hell if you edit your question with a link to the source I could hack this up for you in no time. But if you're doing this as a socket exercise, more power to you :P
You should note that most server admins don't take too kindly too frequent scraping of their site, and you should probably clear it with them, lest you face the repercussions.
Well yes, if the only way to access your email is through webmail then any tool you create will have to use the webmail markup to work out new messages.
Personally I'd try and find out why POP/IMAP isn't allowed. As far as I'm concerned that's a really strange policy.
In precedent job, the only access we had to email was through a webmail (squirrelmail) at the time, I had wrote a Perl script with WWW::Mechanize that went through the pages to fetch the emails, send them via smtp to an external mailbox, delete them, and expunge the trash...
It's was about 20/25 lines of code. Off course, a C version would be a bit bigger because it would not have WWW::Mechanize :-)