I have a C# application that sends emails through smtp.gmail.com. If I ever send about 20 emails, I start getting errors like
The server response was: 4.7.0 Temporary System Problem. Try again later (WS)
Usually, about 17 messages out of 20 ever end up getting sent.
Note that I am not saying 20 messages were sent and only 17 were successfully delivered, I mean that only 17 actually even try to get sent.
I can't find much specific info on this error, but I assume this is related to some kind of a gmail throttling limit, because I don't see this error if I only send like 1-5 emails at a time.
Can someone confirm what this means and why it happens?
Related
In my application about 100 emails (invoices) are sent in a loop, once or twice a week. 99% goes without trouble, but sometimes the user get the error "10054 connectio reset by peer". I know what that means, but the real problem is that the mail wás sent. So, my appliction assumes something went wrong, but the customer receives the invoice. This cause problems in the invoice-numbers (double).
My questions are:
Is there a way to tell if the mail was sent? (eg: eventhandler on "workend")
How is it possible this error occurs AFTER the mail was sent ?
I use the TidSMTP Indy component in Delphi 10.4, the mail is sent via outlook, port 25.
Unfortunatly, it is not possible for me to provide a usefull example, since there is only 1 customer where this occurs,and roughly only in 1 out of 500 mails.
I do not have a trace. Would it be enough to fill all the eventhandlers of the IdSMTP-component and write the parameters to CodeSite?
kind regards,
Dirk Janssens.
We send a lot of email messages from our Siebel 7.8 application, and we'd like to determine whether they have been successfully delivered or not.
According to the Bookshelf, if the SMTP server is down, the Communications Outbound Manager retries to send the message later, so that's not a problem. However, there are still plenty of issues which could cause an email to not be delivered, such as a typo in the address, the receiver having reached its storage quota, etc.
We send our messages this way:
var ps = TheApplication().NewPropertySet();
ps.SetProperty("ActivityId", outboundEmailActivityId);
ps.SetProperty("CommProfile", commProfile);
ps.SetProperty("ProcessMode", "Local");
var bs = TheApplication().GetService("Outbound Communications Manager");
bs.InvokeMethod("SendMessage", ps, psOut);
Using ProcessMode = Local allows us to detect a few errors. For example, if we try to send a message to a non-existant account in the same domain of our SMTP server, it returns 550 Unknown user and then 503 Must have sender and recipient first. The Outbound Communications Manager raises an exception, and we capture and handle it.
However, if we send a message to a non-existant account in a different domain, our SMTP server can't know that it will fail, and therefore it returns 250 Queued, and our code completes successfully. Later (it can range from seconds to a few hours later), we will receive a "Message undeliverable" error message, but at this point we only know that an outbound message failed, we don't know which one.
Is there any way in which Siebel can handle these 'Message undeliverable' notifications automatically?
We are thinking of writing our own process for that, but it seems like a huge task: we'd have to parse the delivery failure notification, identify the failing recipient, search for all the recent messages sent to that address, and somehow, guess which one failed (based on the Message-Id if we are lucky and can read it within Siebel, or on the Subject otherwise).
The problem is that SMTP is by its nature neither a synchronous nor reliable protocol (i.e. in the sense of "engineered for guaranteed delivery"). Your Siebel app server will connect to its assigned SMTP server and ask it to accept a message for delivery and at that time there are a few high level validations that can be perform (some of which you've mentioned but which can also include policy enforcement such as checking whether your (possibly anonymous) identity is authorized for relaying messages to external domains). Once that conversation ends, there is not much else you can reliably do because again, everything from that point is asynchronous and not guaranteed for delivery (any number of intermediate relay agents can be involved, each with their own potential for outages with or without retry, each with the ability to honor or ignore requests for delivery or read receipts or to report invalid recipients, throwing your message in a junk folder or not, etc.). Certainly you can attempt to work with any bounce notifications you do happen to get to try to correlate them back to the sender but that would be outside the context of your sending code.
I'm migrating an app from a CF8 Server to a new CF 10 Server. As I was working with a form that sends an email everything seemed to work as it should and I received a copy of the email. And then another, and another. Every 15 seconds the server would send me the same email.
I took the mail server out of the CF Admin and still the duplicates kept coming. I checked the spool and undeliverable folders and they were both empty. The only thing that stops the emails from being sent is to stop the actual ColdFusion Application Service. When I restarted the service, however, the emails started up again!
I created a simple test page that has only a minimal CFMAIL tag with the basic fields and gave that a try. Same thing. Only now I have two emails coming into my inbox every 15 seconds while the service is running.
The mail log shows the emails being sent but doesn't give any indication of how they are being triggered. I can't understand where these emails might be stuck in the CF Server in a way that they are sent every 15 seconds. I've Googled it mightily with no leads.
Has anyone else experience anything like this? Thanks for any guidance.
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.
I have accidentally started a GmailApp script with infinite loop and now i m receiving bulk mail. I had set an alias for my account and been receiving mail from alias account.
I tried to stop the script by:
Revoked the access to the script
Deleted the alias as well, no success yet
Deleting the script but not working, still receiving the mails
Now i have no idea what to do. I last 30 mins i have received around 500 mail and dont know how to stop these script.
It is unlikely that the script is sending you bulk email because it can send a maximum of 100 emails in a day while you received 500 in 30 minutes.
If you could look into the email headers, it will give you some idea about where these emails are originating from.