CRM email not appearing in queues - email

I have a CRM applicaton with queues setup to receive emails. It is all working as expected except for one exception.
The client is scanning letters that they receive and using a SMTP request via their exchange server to send the scanned letter to the queue in an email message. The message is being delivered to the email address but it is not going into the queue in CRM.
Relaying has been enabled on the exchange server for the CRM system. If the message is sent from a normal email address it enters the queue as expected. There is nothing in the Trace logs or the event viewer on the CRM server to indicate why the message is not going into the queue.
Can anybody provide me with some suggestions as to why this could be happening?
Thanks,
Neil

Turns out the mails weren't entering the mailbox at all

Related

SQL Server 2014 - DB mail sending Issue

DB mail was working fine using SQL Server 2014; however since we moved our email to Office365 online Exchange, we are having issue. Whenever there are rapidly generated emails by our application; then sending emails is stopped with following message:
The mail could not be sent to the recipients because of the mail server failure. (Sending Mail using Account 3 (2018-04-08T08:25:06).
Exception Message: Cannot send mails to mail server. (Failure sending mail.)
Service again starts sending emails automatically after a lag of few hours.
I have already checked email account separately and it is working fine.
This is a limit set by Office 365. Check this image captured from microsoft technet post
Based on your subscription, limits are there for sending total emails per day as well as bulk email at a time. Same has been confirmed in this Microsoft blog question
That's why your task stops sending email for sometime to reset its Recipient limit.

Multiple emails when triggered from SendGrid remain undelivered and stay in "Processed" state

I am using SendGrid to send email notifications. I have a requirement where I send multiple reminder emails once a day.
Currently, I am facing an issue with this. When the emails are triggered, ideally 5 emails should be sent from the application but instead of that only 1 mail is received. When checked in the logs and SendGrid dashboard it is observed that the emails are triggered but they stay in a Processed state which stops them from being delivered to the respective recipients.
I am not understanding what is this issue about and why is this happening even after receiving success code from SendGrid.
The success code from SendGrid just means that they received the message properly from you. Email is asynchronous, and the SendGrid 200 doesn't mean the message was delivered. In your SendGrid Email Activity, look and see if you have Deferred events for those additional messages; trying to send multiple messages to the same address at the same moment may be causing warmup-based deferrals, until the receiving system trusts you.

SOA UMS Email Populating black list

I'm sending email notifications through SOA using UMS. However, email server has a limit on the amount of emails sent and some go to invalid emails.
I'm trying to find a way to retrieve notifications of message delivery failure in order to populate a black list. SOA human workflow notifications are sucessfully sent despite the email address, they only record status on gateway delivery. Email client is not registering sent notifications nor is it receiving delivery failure notifications. (Unless I send an email through the email client, not from SOA)
Basically, I would like to know if UMS stores information of delivery failure to recipient (not gateway) and if so how can I access it. In alternative, how can I setup email client to register sent notifications and receive failure reports that can somehow be passed to SOA so they can be analyzed and the email added to a black list.
Any info missing that can help solving this issue just ask and I'll append it to the post.
Best regards,
Martin
You can create an inbound UMS adapter polling the inbox to read all the incoming mails. UMS adapter has a filtering option to read only mails that matches the pattern. Set the pattern to read only delivery failure notifications. That way the polling service will get triggered only for messages with delivery failure.
Try this out and let me know if this solve your problem.
Regards,
Viv

(Mailgun) Inbound route catch_all() not forwarding autoreplies

This one has me stumped... I currently have one MailGun route setup... its a catch_all() that forwards all mail on my domain to my GMail account. For some reason, if I email somebody who has an autoreply (i.e. an out-of-office responder), I do not receive the autoreply message. I checked the MailGun control panel logs, and the autoreply never even shows up... its as if messages sent via MailGun don't trigger other mail services to send an autoreply? I've confirmed that my sent messages are received in the Inbox of the person with the autoreply active. I've also confirmed the behavior when sending to outlook and GMail users.
Help please! Thanks.
Here's a response I got from mailgun support:
We by default drop all system messages, NDRs, OOOs and auto-replies (they'll all have a null <> Sender header which don't allow).

Emails always queued with status 250

My application uses Simple E-mail Service from AWS + GoogleMail for sending mails to clients.
But I have a lot of complaints about mail never received, even after more than 24 hours.
In the logs, I see:
250 2.0.0 Ok: queued as XXXXXXX
reportingMTA: a9-82.smtp-out.amazonses.com
Can anyone tell me:
Is e-mail queued on Amazon OR on recipient server?
Where can I find rules to help me avoid that?
This means Amazon 'did their job' by delivering the message and having it accepted.
What implies that you shouldn't want to avoid this to happen.
The problem is, as Amazon says:
Amazon SES successfully delivers the email to the recipient's mail
server. This notification does not indicate that the actual recipient
received the email because Amazon SES cannot control what happens to
an email after the receiving mail server accepts it. Delivery
notifications are available only through Amazon SNS.
I was in the very situation you are, I had some complaints about never receiving the message. What I realized after a lot of analysis:
There was in fact emails that after being said as delivered, later on came back as 'marked as spam' messages -> I asked them to whitelist my domain
I myself had a flaw in my verification of whether to send email to a client or not ( I was blacklisting all recipients in a batch if any of them sent back a "Permanent Bounce" response)
There was even cases of people saying that didn't receive (because they heard that some other people weren't actually receiving) and investigating further I found out they had in fact received but were just too lazy to take a look to give me correct information (!)
I found many types of "Successfully delivered notifications" (such as "250 2.0.0 Ok: queued as XXXXXXX", "250 ok: Message XXXXXXX accepted", "250 2.6.0 Queued mail for delivery", etc) and I thought there could be a problem related to this "queued" responses, but in the end I found none.
My advice is that you investigate further other possible reasons just like I did.