I am using Gmail servers to send email from my system, with a program.
Recently I started getting errors like this:
Data command failed: 421 4.7.0 Temporary System Problem. Try again later (WS). 6sm3756432pab.11 - gsmtp
The reasons are given in the support.
Can anybody tell me what is the number of emails that can trigger this issue?
Or is it because of some other reasons?
If you are using your free Gmail account to send bulk emails your are likely to see this kind of responses early on as the service is not intended to send application transaction messages, newsletters etc., event to subscribers that has opted in.
The IMAP/SMTP service provided is for you to be able to use an email client like Microsoft Outlook with your Gmail account.
If you need to send transaction messages, I suggest you google "AWS SES" for starters.
I agree with Anubhav Shrimali that the error occurs if Gmail gets multiple requests simultaneously.
I had solved the problem using Nodemailer in Node.js by adding the 1 second delay between each successive email as follows:
array.foreach(function(data, index) {
setTimeout(() => {
sendmail();
}, 1000 * index);
function sendmail() {
transporter.sendMail(mailOptions, function (error, info) {
if (error) {
console.log(error);
} else {
console.log('Email sent' + info.response);
}
});
}
});
This error occurs if you are using scripts to send emails in quick successions.
An easy way out is to apply a sleep timer in between sending emails.
I applied a timer for 1 second between each successive email.
import time
time.sleep(1) // equivalent to 1 second sleep
I too had the same issue when I tried to send bulk emails using the multi threaded program in Java. Then I heard about Thread Pool Executor. I used it by setting Thread Pool size as 10. After that, this issue has been solved for me.
If this situation is encountered, it should be placed in the retry queue, and the monitoring will be notified if multiple retries fail.
Hope this link can help you：
https://support.google.com/a/answer/3726730
This is probably a result of bulk email sending from the same IP address. As mentioned, use the python sleep function so that there is a bit of a wait between sendings. I find that 1 second is not usually enough time for me, and I sometimes go with a random number of seconds between 1 and 5 for the most optimal results.
import random
import time
time.sleep(random.randint(1, 5))
Don't forget to import the correct modules.
have a rest for 20 minutes , and try again, the error gone
Related
My org sends some 3000 high value (invoices/receipts/statements) per day on behalf of itself and some 10 broker customers. I cannot control email recipients and need ALL bounced emails to be returned to the From: address (these vary per broker) - so they can be actioned. In a nutshell I send from some 10 distinct domains to some 400 distinct destination domains and cannot afford to have emails go missing.
After a bounce occurs, SG adds the recipient to a bounce suppression list and any subsequent emails are then dropped/lost.
The app.sendgrid.com GUI allows me to configure an Allow list where I can enumerate destination domains to be excluded from the suppression process, however I have no control of the destination domains and this is an ever changing list. Not practical.
SendGrid recommended the use of the API, but have just confirmed that this is not a permanent setting but something that needs to be done on a message basis.
My message source is via a dedicated Postfix server via a simple SMTP connector. We are not using the API. I can modify the Postfix server if required.
The API/json payload recommended by SG is:
"mail_settings": {
"bypass_list_management": {
"enable": "boolean (optional)"
}
}
But I am really not sure on how to implement this if this is really required on a per message basis. Possibly using Postfix?
Has anyone else run into the issue? Any recommendation? It is disappointing to say the least that a key feature such as bounce protection cannot be turned off at a GUI level.
Any suggestions on how to solve my predicament?
I can now confirm that prepending:
X-SMTPAPI: { "filters": { "bypass_list_management": { "settings": { "enable": 1 } } } }
Works as expected and undeliverable messages are returned to sender. TY SG support.
Hello I have a google docs document where I installed a simple emailing code on as follows:
function sendMail() {
var file = DriveApp.getFileById('XXXXXXXX');
var recipients = "mymail#group1.com" + "mymail#group2.com" + "mymail#group3.com";
MailApp.sendEmail(recipients, 'Daily Notes', 'Please see file Attached.', {
name: file.getName(),
attachments: [file.getAs(MimeType.PDF)]
});
}
The code works fine it sends the email to multiple group emails which I want it to send. It has done this for a month now. But until recently, I keep receiving this Mail Delivery Subsystem after 20 minutes or 1 hour from the original email which is sent out and inside the error message email it says:
"The following addresses had permanent fatal errors"
and it points to only one of the emails I send daily mails to. It also says something like this: (reason: 554 5.4.6 Too many hops). and then this:
554 5.4.6 Too many hops 53 (50 max).
The Good Doc's file has Google's time-driven trigger as you can see in the image below. I wonder if somehow the trigger is running twice in the time interval I gave to it. Could it be why this is happening?
In almost all cases 554 5.4.6 Too many hops 53 (50 max) means loop along email delivery path e.g. server A forwards to server B, server B forwards to server A, server A forwards to sever B, …. It is detected by counting Received: headers in message passing via give SMTP/email server.
Suggested fixing procedure:
Inspect Reveived: headers in email bounce message to locate server(s) responsible for the loop.
contact the relevant postmaster
In many years I have seen just one "real life" case when bounce message/email like that was not caused by email delivery loop.
Background
We're building an application that will process & send emails via Mailgun. These are sometimes one-off messages, initiated by a transaction. Some emails, though, will be sent to 30k+ at once.
Eg, a newsletter to all members.
Considerations
Mailgun offers a Batch Sending option with their API. Using "Recipient Variables", you can include dynamic values that are paired with a particular user.
This Batch Sending functionality is limited, however. You cannot send more than 1,000 recipients per request, which means we have to iterate through a recipient list (on our database) for each set of 1,000. Mailgun provides an example of how this might work, using Python (scroll about 2/3 down).
Question
Are there any advantages to batch sending (ie, sending an email to a group of recipients through a single API call, using recipient variables) as opposed to making our own loop, variable substitutions and individual API calls?
I assume this is more taxing on our server, as it would be processing each message itself, instead of just offloading all that data to Mailgun's server for heavy-lifting on their end. But I also like the flexibility & simplicity of handling that on our end and sending a "fully-rendered" message to Mailgun, one at a time, without having to iterate 1k at a time.
Any thoughts on best practices, or considerations we should take into account?
Stumbled onto this today, and felt it provided a pretty good summary/answer for my original question. I wanted to post this as an answer, in case anybody else has this question and hasn't found this Mailgun post. Straight from the horse's mouth, too. The nutshell version:
For PHP, at least, the SDK has a Mailgun class, with a BatchMessage() method. This actually handles the counting of recipients for you, so you can just queue up as many email addresses as you want (ie, more than 1k) and Mailgun will fire off to the API endpoint as needed. Pretty slick!
Here's their original wording, plus a link to the page.
Sending a message with Mailgun PHP SDK + Batch Message:
Batch Message
In addition to Message Builder, we have Batch Message. This class
allows you to build a message and submit a template message in
batches, up to 1,000 recipients per post. The benefit of using this
class is that the recipients tally is monitored and will automatically
submit the message to the endpoint when you've added the 1,000th
recipient. This means you can build your message and begin iterating
through your database. Forget about sending the message, the SDK will
keep track of posting to the API when necessary.
// First, instantiate the SDK with your API credentials and define your domain.
$mgClient = new Mailgun("key-example");
$domain = "example.com";
// Next, instantiate a Message Builder object from the SDK, pass in your sending domain.
$batchMsg = $mgClient->BatchMessage($domain);
// Define the from address.
$batchMsg->setFromAddress("dwight#example.com",
array("first"=>"Dwight", "last" => "Schrute"));
// Define the subject.
$batchMsg->setSubject("Help!");
// Define the body of the message.
$batchMsg->setTextBody("The printer is on fire!");
// Next, let's add a few recipients to the batch job.
$batchMsg->addToRecipient("pam#example.com",
array("first" => "pam", "last" => "Beesly"));
$batchMsg->addToRecipient("jim#example.com",
array("first" => "Jim", "last" => "Halpert"));
$batchMsg->addToRecipient("andy#example.com",
array("first" => "Andy", "last" => "Bernard"));
// ...etc...etc...
// After 1,000 recipeints,
// Batch Message will automatically post your message to the messages endpoint.
// Call finalize() to send any remaining recipients still in the buffer.
$batchMsg->finalize();
The answer of #cdwyer and #nikoshr is very helpful, but bit legacy. Used methods in the example are deprecated. Here is current usage of lib:
$batchMessage = $this->mailgun->messages()->getBatchMessage('mydomain.com');
$batchMessage->setFromAddress('user#domain.com');
$batchMessage->setReplyToAddress('user2#domain.com');
$batchMessage->setSubject('Contact form | Company');
$batchMessage->setHtmlBody('<html>...</html>');
foreach ($recipients as $recipient) {
$batchMessage->addToRecipient($recipient);
}
$batchMessage->finalize();
More info at documentation.
When reading the Sidekiq Wiki I see the following examples:
From Getting started:
Send a message to be processed asynchronously:
HardWorker.perform_async('bob', 5)
You can also send messages by calling the delay method on a class method:
User.delay.do_some_stuff(current_user.id, 20)
Also, from Delayed extensions:
Use delay to deliver your emails asynchronously. Use delay_for(interval) or delay_until(time) to deliver the email at some point in the future.
UserMailer.delay.welcome_email(#user.id)
UserMailer.delay_for(5.days).find_more_friends_email(#user.id)
UserMailer.delay_until(5.days.from_now).find_more_friends_email(#user.id)
So what is actually the difference between perfrom_async and delay? In which situations would I prefer the one over the other?
perform_async is Sidekiq's native API. delay is a compatibility API with DelayedJob. Use perform_async when possible.
Is there any way to purge an outgoing queue. It doesn't appear that I can do it with the MMC snap-in and when i try to purge it in code i get an error Format name is invalid the computer it's sending the messages to does not exist, so they will never be sent, however the queues filled up the max storage space for MSMQ so everytime my application tries to send another message i get the insufficient resources exception.
I've tried the following formats and they all fail with the exception format name is invalid
DIRECT=OS:COMPUTER\private$\queuename
OS:COMPUTER\private$\queuename
COMPUTER\private$\queuename
You should be able to purge it manually from the MMC snap-in. MSMQ gets very stingy when it reaches its storage limits, so a lot of operations will fail with "permission denied" and things like that.
The long-term solution obviously is to modify the configuration so there is enough storage space for your particular usage patterns.
Edit: You might be running into a limitation in the managed API related to admin capabilities and remote queues. Take a look at this article by Ingo Rammer. It even includes a p-invoke example.
it is possible use managed code to purge an outgoing queue:
using (var msgQueue = new MessageQueue(GetPrivateMqPath(queueName, remoteIP), QueueAccessMode.ReceiveAndAdmin))
{
msgQueue.Purge();
}
in which GetPrivateMqPath is:
if (!string.IsNullOrEmpty(remoteIP))
return String.Format("FORMATNAME:DIRECT=TCP:{0}\\private$\\{1}", remoteIP, queueName);
else
return #".\private$\" + queueName;
QueueAccessMode.ReceiveAndAdmin points to outgoing queue.
You could try FORMATNAME:DIRECT=OS:computer\PRIVATE$\queuename.