I am receiving chart data in JSON format to my email address and my goal is to convert it to chart/chart img and resend it to my email address.
I have been looking for several methods:
Google App script used for gmail. I failed to find trigger on newly received message.
Email client, that supports adding actions based on scripts to new incoming message trigger. Only one I know about is MS Outlook with VBA scripts, but creating chart image with lack of libraries available in VBA is not very elegant solution.
Open source email client with possibility to alter the code and so directly process data and resend message. The more robust email client, the harder is to change the code to do relatively simple job, I believe.
I really don´t know what kind of solution this simple problem needs.
Thank you in advance.
Sounds like you are interested in some kind of gateway on the server side, not client-side. Take a closer look at your server-side implementation. For example, you may start from the Mail flow rules (transport rules) in Exchange Online page.
Related
so i was wondering if its possible to make a email bot that reads mails and reply accordingly?
It should work like an enhanced chat bot.
I have googled but came across nothing.
Any platform/technology will work.
Thanks
This question is better separated into its parts, try breaking the task down into 3 separate subtasks.
part 1 - hook emails into an API
I suggest looking at something like MailGun: https://www.mailgun.com/
part 2 - use chatbot logic to determine an appropriate reply
A good example of a versatile chatbot is here:
https://www.pandorabots.com/
part 3 - use an emailer script to compile and send a reply
Which you can then do using MailGun, or something more generic like PHPMailer
All in all once you have used something like mailgun to receive the email, it can be stored in a database or parsed as JSON. From here you can do whatever kind of manipulation you want based on requirements. Something more autonomous would parse that JSON into a chatbot to determine the reply then send off the reply right away. Something a little more manual would be to store the email into a database, then use a cron job to pick up new emails at an interval (every x seconds/minutes/hours/etc) and process the chatbox and reply logic from there.
Hope this helps!
Was hoping for some ideas as to a service to which I can set up an inbound-only email system. In other words, I will have multiple users on the system, each can receive their own email... but at the moment... at this time, I am not focused on the ability to send or reply to messages, only receive them and send to the appropriate user. I looked into Postmark... They seem to have some great functionality.
CloudMailin Is another alternative. However there are effectively three options for setting up something like this.
Use an existing, traditional, email server and poll for the emails
Setup your own email server and create a script to run when you receive an email
Use a third party solution, as you've already mentioned.
I went through for of these for Rails a little while back here, but all the information is still relevant.
First, let me get this out of the way and say this isn't a spam application. I'm writing an app that allows users to share files with multiple friends easily via email.
Right now, I'm using SKPSMTPMessage to send out emails to a list of recipients at the user's request. It works, but I wonder if there isn't a better solution here. For example, if it might be better to send the smtp info and attachments to my server, and conduct the sending from there in order to avoid repetitive attachment uploads on the device.
I am also considering how to handle cases where there is no connection available (determining connection error vs other kinds of errors and persisting the failed message for a later retry).
Any advice on the best way to structure this service would be greatly appreciated.
In order to customize the user experience for sending e-mail you need access to their email details, IMAP, POP, etc. if you want that user to be the one sending the e-mail.
The solution I use is to have the from address be an e-mail I control and use a 3rd party email provider, ex: SendGrid, PostMark, Mandrill and plug in to their api's to send e-mails.
I'm sending newsletter using Zend Mail. I have used setReturnPath() to put all undelivered mail notifications in one place.
And what now?
How to get the list of addresses which were unreachable?
How do I read and parse the returned notifications?
How to know whether the mail returned because of non existing email or just quota exceeded?
Which headers do I need to send and check?
Related:
Variable Envelope Return Pathwiki
Handling undelivered emails in web appso
This class may be helpful. Can determine whether the mail is a bounce and return a response code with description:
http://www.phpclasses.org/package/2691-PHP-Parse-bounced-e-mail-message-reports.html
Short Answer:
you can't do that in a simple way and not in your app.
Long Answer:
You should handle that in asynchronous way and outside your php app (at least in part). First of all you must setup the return address to something like sender+recipient=recipientdomain.com#senderdomain.com as in the TimB answer. At this point all the notification sent by receiving smtp server will go to that address.
Then you need to setup the smtp daemon at senderdomain.com mail exchanger to handle that kind of bounce messages and process them in some sort of pipe.
With a pipe you can forward the returned message to an external program which parse the message and extract the needed informations (i.e. the reason why the delivery is failed)
At that point in your program (which can be a cli script in your application) you can mark the address as failing and optionally can record why.
This is a pretty difficult task, which can't be handled in a simple application. Usually I use a dedicated software for large mailing list handling such as sympa which takes care of this task for you.
Otherwise you can use an external delivery service such as Sendgrid which will do the dirty job for you and report the failing addresses with a simple API. As a bonus with this solution, they are in the whitelists for all the major providers, so your email won't be marked as spam as far as you respect some simple rules (i.e. removing bouncing addresses and use an opt-in policy for your newsletter)
Well, the second link and especially the answer by TimB explains very well the procedure.
What may not be clear is that the return path is nothing other than a regular email account, i.e. you will get the email to that address. Zend_Mail is not waiting for a response and hence there is no list of addresses.
I have an application that sends emails when a user creates/modifies a record. I would like my users to be able to reply to the email that was sent to them and have the web application receive the email, parse it and update the record automatically. I have seen this done in web apps like Basecamp. The email usually says "Reply above this line", and if you simply reply to the email, you don't have to log in to the web application in order to update your ticket/conversation.
How can I go about implementing this sort of functionaly? (I'm not looking for a particular language implementation, but rather a language agnostic solution).
There are 2 ways you can do this:
You could use a Procmail filter to pipe the incoming email to your script. This would need some 'nix knowhow to setup - but it's certainly possible to do what you described via this method.
Use a service like MailGun - they do all the hard work of setting up and configuring the mail server stuff and expose it to you via a nice programmable web API. I've been evaluating it this week to solve a similar problem like the one you are having and I can tell you: it is really cool and I highly recommend you check it out yourself.
You'll need to implement a service/daemon that polls an email inbox for new messages. To relate an incoming email to the corresponding data, you can include an id in the outgoing email's subject.
I agree you should created a system to receive the incoming email but I don't necessarily agree that polling for it is the correct solution. Take a look at a blog post I wrote on the subject here. It relates to Rails but the concepts should work in any language. That's why we wrote the CloudMailin system to provide a better way of receiving the email.
Also you can use a unique from address for each email that would prevent the user from altering the subject line being a problem. The disposable part of an email address is useful for that. reply+user123#example.com for example.