When emails sent through javamail are automatically forwarded to invalid email addresses the smtp service counts them as bounces against our performance even though the original email was delivered. Is there a way in javamail to prevent auto forwarding of the email?
Related
I have created Azure Logic App with Recurrence trigger and then used SendGrid connector for sending emails to multiple team members.
I didn’t receive any email even though the logic app actions executed successfully. After that I have checked SendGrid account email activity status, it is having “Delivered” status for the mentioned to email address in the SendGrid action.
Note: I have whitelisted the Outbound IP address of my logic app in SendGrid IP Address Management.
Twilio SendGrid developer evangelist here.
I don't know how Azure Logic Apps trigger emails with SendGrid, but if an email isn't being sent they shouldn't be getting the "Delivered" status.
You said that you have not set up Single Sender Verification or Domain Authentication. In order to send an email using SendGrid from the email address you provide, that email address should either have been verified as a Single Sender (which is mostly useful for testing) or it should be from a domain that you have authenticated with SendGrid.
Try setting one of those verification methods up and then try sending emails again.
We have a problem with all emails sent via our Gmail API App.
All of them deliver with a warning about the safety of the email
This message seems dangerous. Many people marked similar messages as phishing scams, so this might contain unsafe content. Avoid clicking links, downloading attachments, or replying with personal information.
This happens only when sending an email through our Gmail API but when sent via SMTP will deliver the message without any warning.
This warning message appears on all emails sent via our Gmail API Application, no matter if the sender is a Google workspace user or a free Gmail user.
Can anyone help on this?
Messages sent through the Gmail API to a Gmail address are getting tagged in Gmail with
Be careful with this message. It contains content that's typically used to steal personal information.
The message basically just says test. And the identical content message sent through Gmail SMTP doesn't get tagged with that warning.
It seems really strange that Gmail would mark messages that are coming through a Gmail owned API as suspicious but when they come through SMTP it does not warn about it.
I was getting this as well. Simply removing the 'from' portion of the email solved it for me. If you are authenticated gmail figures that stuff out on its own.
Although this Google document describes a simple way for a GAE app to send a message to a Talk/Chat user, apparently this feature has been discontinued. Is there another method for a GAE app to send a message to a Talk/Chat user?
As an aside: for SMS'es from real phones sent to my Google Voice number, each SMS received is also received as an email in my Gmail account. And the sender of the email is 18888888888.19999999999.somegibberishchars-#txt.voice.gmail.com, where 1888... is my GV number and 1999... is the sender of the SMS. I can reply an SMS to the sender by simply sending mail to this email address. This email address does not expire, ie I can still send SMS'es using this months later.
Is there a similar way to deliver messages to Talk/Chat by sending to a specially formatted email address?
I am using the XMPPservice's sendMessage method
to send a message to google mail but the message
can not be sent without any error log.
Thank
A common error source is that the receiver first has to accept an invite from the sender. Only then messages will be relayed to the receiver. Have you sent an invite and was it accepted?
If the Gmail recipient is using Google Apps (e.g. Google Apps for Business), the recipient domain must publish SRV records in their DNS to allow routing of the XMPP packets to the Gmail Chat backend. The vast majority of Google Apps domains will not likely have SRV records configured.
If the recipient is a #gmail.com / #googlemail.com account, then (as #schuppe suggest) the most likely cause of this issue is due to the fact that the recipient did not accept the invite from the sender.