When using Azure Logic App Office 365 Outlook connector - "Send an email", is there a way to find out if the email was actually delivered or not to the recipient so as to take a specific action based on the failure?
I used an invalid email ID in the connector, but the action of sending email is shown as successful even though the email was not delivered. To confirm it is an invalid email ID, I sent email to this invalid email ID from my Outlook and I received an undelivered email message.
In the next action after this “Send an email” action, I selected the 3 options (has failed, is skipped, has timed out) under “Configure run after”. However, this action is never executed as the email sending action is always successful even though the email was never delivered to the user.
Below is a screenshot of my logic app. The bottom right action in yellow is never executed even though the email is not sent in the previous step.
Send Email Logic App
Any inputs on how I can find out if the email was actually delivered or not?
My goal here is to find out if the user actually received the email or not, and then take some action if the email delivery failed.
No, this is not possible from within the Logic App.
The only way to occasionally accomplish this is to monitor the sender inbox for NDRs (Non-Delivery Receipt). This can take minutes to hours.
Be aware, a number of email systems will not even send NDRs as they can be used to fish for email addresses.
You can use get emails action to get the latest email and you can perform the next action based on the condition whether the subject of the email we get contains the "Undelivered" string.
Sometimes it takes long to receive the undelivered report email in outlook. so i made a specific flow which will extract the wrong email that i sent the mail to and send me an adaptive card with that email provided in it.
Related
I want to process shared box emails once in a day by logic app. I tried using Get emails(v3) and when I am trying to login into shared box with email then it connects to my email id as shared mail box has email id but user account is linked / given permissions by the user how have access to it.
I am able to view my emails by Get emails (V3) action. how can I view Inbox by Get emails V3 action on shared email box.
I do not want to process email immediately like in "when a new email arrives in a shared mailbox"
AFAIK, Yes you can add an recurrence step before the step of when a new email arrives in a shared mailbox as below:
Fisrtly, add recurrence trigger as below for 1 day as below:
then click on get mails action as below:
or you can use the below action:
By using this we can get the unread messages on a given particular day.
What Azure service allows us to run at a fixed interval (IE every 5 min), and if a given Outlook/mailbox folder has one or more emails in it, then send one notification email?
We have a Logic App that does email processing. If the processing fails for whatever reason, the email is placed into a "Failed" folder, and an email notification is sent out. The issue is when a dependent service is down, we are getting hundreds of email an hour.
We tried creating a second Logic App that runs every 5 min, sending email if it found email in the folder that is "flagged", but we still received one email per flagged email.
We are thinking a separate service that runs every so often, and if a folder has email in it, then send out a single email.
Actually there is a Outlook trigger action to detect if there is an email is flagged. It supports to change the Folder,Importance,Interval and add other parameters to match.
And this is the action Optional Parameters description.
We will be sending automated emails through a mail box ,we will send an email with two to three emails in TO column and one or more emails in the CC column ,if i have a wrong email in the TO column in that mail box we will get a delivery report that email is wrong i need to write a program such that it will pick up the wrong email id
Start by reading up on JavaMail FAQ and the com.sun.mail.dsn package. The JavaMail Homepage has all of the downloads you'll need.
You could also enable the mail.smtp.reportsuccess property per the documentation:
When sending a message, detailed information on each address that fails is available in an SMTPAddressFailedException chained off the top level SendFailedException that is thrown. In addition, if the mail.smtp.reportsuccess property is set, an SMTPAddressSucceededException will be included in the list for each address that is successful. Note that this will cause a top level SendFailedException to be thrown even though the send was successful.
I am using cakephp framework for my web application development. My application will send welcome email after user entering his information. After this only it will display 'Sign Success' message. Unfortunately CakeEmail taking around 6 seconds to send a mail, so my sign up approximately taking 8 seconds. So how can I speed up the sign up process without removing CakeEmail.
You should defer sending of the email so that the user doesn't have to wait for the email to be sent before rendering any content. Whether the email has been sent or not makes no difference to the user seeing your 'Sign Success' page so shouldn't be responsible for increasing page response time.
Take a look at using something like the Queue plugin for CakePHP to defer sending of email. This would allow you to log that an email needs to be sent after the user's data has been saved. You'd then setup a task for sending the email. The task would executed the next time the queue is run (for example, by a cronjob).
The scenario is that users of web application can purchase digital items. The web application will use Paypal Instant Payment Notification.
The IPN protocol consists of three steps:
PayPal sends your IPN listener a message that notifies you of the event
Your listener sends the complete unaltered message back to PayPal; the message must contain the same fields in the same order and be encoded in the same way as the original message
PayPal sends a single word back, which is either VERIFIED if the message originated with PayPal or INVALID if there is any discrepancy with what was originally sent.
Let's say it's VERIFIED, how could I know who have completed the transaction or purchased the item (user of the web application) if the user used other email address in his/her paypal? I have stored the email address of the user in session but what if he/she have different paypal email? Paypal email is included in IPN message.
For other details, maybe not useful, the application is written in Struts2 in Google-App-Engine.
You'll need a way to correlate the IPN data coming back with the user. Either by asking them to provide their paypal email or using the username/password generation facility in the IPN service. Here is a somewhat inelegant but functional approach:
When the IPN comes in off the wire, persist the paypal generated username/password and payer_id (in perhaps the datastore).
If you can't correlate by email, then when the user comes back to your site request that they enter the username/password generated from paypal's site once (just to correlate).
Lookup the username/password and then correlate their userid from the UserService back to the payerid.
The reason to use IPN is for subscription services as you can get IPN messages when the subscription is terminated, cancelled, or when payments come in (for an account that stopped paying).
The most important thing to think about is how to correlate a user of your site back to the payer_id (or even payer_ids in some cases) that are used to pay for the services they are using.
On another note, I wouldn't use the session to store information for IPN callbacks, those actually can take a LONG time sometimes (say when the x.com conference is on and everyone is hammering paypal).
If you have a running application or a better description of the look & feel, I might be able to come up with a more elegant suggestion. Let me know if this helps at all.
Why don't you use PayPal's express checkout? This way you negotiate server2server a token and then you can check with PayPal the result of that token on user's return.
If users are buying directly from your application it's easier to implement.
And I think it'is more robust than the method you're using (I never heard of it before :D )