I have webhooks set up for bounces, clicks, opens, failures, and deliveries.
Clicks, opens, and deliveries all work. In my logs I see that I have no red permanent failures, but lots of orange temporary failure events such as 429, 451, 499. Neither the failure nor the bounce webhook has ever been triggered. I know they are set up correctly on my end since the "Test Webhook" link does trigger them in my Mailguin control panel.
Is this expected behavior, ie, are only some bounces, or only after n-tries, does the webhook actually get hit, or is something wrong on my or Mailgun's end?
I'm using the PHP API to send messages, if it matters.
Related
Prerequisites
I use AWS SES to send an email with event publishing to track the delivery status.
Problem
I'm looking for an event to make sure that an email is successfully sent to the end-user.
Description
Following AWS documentation, this type is suitable:
Deliveries – Amazon SES successfully delivered the email to the
recipient's mail server.
However, this event I get also in case Hard bounces.
For example, email status flow is:
Sends -> Deliveries - in case of successfull delivery
Sends -> Deliveries -> Hard bounces - in case I provide invalid recipient name, e.g. invalid#domain.com or 1234567890#domain.com
I don't expect Hard bounces after Deliveries.
If this behavior is correct then I need some additional event for sure success.
Something like this is expected in case of successfull delivery:
Sends -> Deliveries -> Success
I know that there are other "success" events like Opens, Clicks, Subscriptions, but they require additional action from the end-user.
Implementation details
I use Verified identity as an email sender.
A configuration set is used to redirect status events to SNS.
Finally, SQS is subscribed to this SNS to have all events in one place.
I tried several ways to send an email:
Java code using AWS SES SDK
Sending simulator with predefined and custom recipient's
The result is the same (as described above)
I think it is impossible to have a Success status because AWS cannot guarantee when the recipient mail server will reply with a Hard Bounce. You yourself have to define how long to you want to wait until you consider a delivery as successful. For example, if no hard bounce after 5 minutes, then it is a success.
If your use case is for analytics, I will simply capture more event types (for example log both Deliveries and Hard Bounces), and then count my success as Count of Deliveries - Count of Hard Bounces.
If your use case is for event-driven workloads, we need to define first what is considered a Success. For example, if we define Success as no Hard Bounce after 5 minutes, we can configure a Lambda function to trigger 5 minutes after a Delivery event. In the function, check if a subsequent Bounce event occurred. If not, the delivery is considered successful and then you can proceed to do what you want to do.
This is what I got from aws support about delivery status of an email.
Amazon SES will continue making several delivery attempts until
receiving a successful response from the recipient mail server, or
until 840 minutes elapse. If Amazon SES is still unable to deliver
the email/message during this period, it stops sending the email and
will then return a bounce message/notification.
According to this you can't be sure about the bounce or any other status within 5 minutes.
AWS does not have visibility to confirm if the Recipient Mail Server was able to deliver the message to the recipient email address when you get a 250 OK(it's confirmation that aws has delivered the message to recipient's mail server).
So there is no way you can be sure.
If I send a message to my own phone, it gets received properly. If I send it to my wife or son's phone, the message does not get received. Despite this, the SNS dashboard says that the messages were properly sent. I hope I'm missing something, but at this point, I don't feel like I can use SNS for customer facing apps if all the feedback I get says it worked fine, but I can't guarantee that the users actually receive a text. This is the first time I've used SNS in this way. Is this expected behavior or am I maybe missing something?
We ran into this issues a few times and hope to find a workaround.
screenshot of Cloud PubSub web console
As in the picture, the PubSub topic has a push subscription on it. When 'VIEW MESSAGES' was clicked, the side panel seemed to allow the user to choose a subscription. But when the user clicked on it, it was not showing the subscription. As a result, the user was not able to 'view messages'.
Is the type of subscription related to this issue or is this functionality not available? If it is related, is there a way to see messages for a topic with only a push subscription?
A push subscription don't stack the message. Each time there is a message, the push subscription sent it to the HTTP endpoint. Because of this, the subscription is always "empty".(This is not exactly true, the not acked message are in memory and are retried until the reception of HTTP code 2XX of the TTL expiration (7 days by default). But there is nothing really stored, at rest)
At the opposite, the pull subscription stack the message until the polling by a client. By the way, you can see the messages stacked.
When I debug a push subscription, especially for seeing what is the structure, the type of message and to validate this, I create a pull subscription in addition and I look into it the messages published in the topic.
I want to get notifications by email for errors on my google cloud service.
It seemed pretty easy to setup. I just hit turn on notifications in Error Reporting in Stackdriver for all services (I only have 1 service).
I created some errors for testing, but didnt receive any emails.
Went into alert policy and profiles and added email notification as a channel. Still not notifications via email.
What am I doing wrong?
I think the best way to check if the notification is actually being sent is to post a test error message manually to the error reporting API.
First, verify that error notifications are available for the project, and then, run the following command on your cloud shell:
gcloud beta error-reporting events report --verbosity=debug --service Manual --service-version test1 \
--message "java.lang.TestError: msg
at com.example.TestClass.test(TestClass.java:51)
at com.example.AnotherClass(AnotherClass.java:25)"
You should receive an email from StackdriverNotifications-noreply#google.com
If you receive the notification for the test, your other errors might be misconfigured. If you don't receive it, then you might need to verify that the noreply address is not being blocked by your provider/filters.
We're doing everything we can think of to limit the number of complaints we receive and will immediately remove anyone who marks us as junk that does not need to receive our emails. However, the last handful of complaints we've received have come from transactional emails of people who are receiving our company's services and NEED to receive everything we send transactionally as a critical part of our service. (e.g. We are booking their travel on their behalf and we need to send them verification emails to confirm their booking details.)
We're assuming that most of these complaints are somehow either false positives or are being done on accident. One customer confirmed that they did not click the junk mail button but it ended up in their junk folder and they moved it to their inbox. Some questions:
Can a TiS complaint be triggered by any means other than the user manually marking an email as junk in their email client? (Can automatic spam filters trigger this complaint? AWS documentation specifies only clicking the junk button.)
Besides contacting each individual personally, what would you suggest we do? Our complaint rate is continuing to rise even though we are taking action on every one.