Amazon SES incorrect email send count

Your software
My Mautic version is: 4.4.7
My PHP version is: 7.4.33
My Database type and version is: Maria DB 10

Your problem
My problem is:

This might seem SES related but its certainly not because I’m not sure if something is wrong in my Mautic setup.

I just sent my first broadcast email via SES, in mautic i can see it sent to 2069 contacts:

In Amazon Cloudwatch panel I can see 2069 emails sent:

However, for the past 2 hours I have been refreshing this panel in SES and it still shows 593:

I’m not sure if SES dropped the remaining emails or something? I see that i can send 14 emails per second:

I have my broadcast cronjob batch set to 13

mautic:broadcasts:send --batch=13

I don’t however have any limits set on mautic:emails:send …so im not sure if that might have been an issue? Would Amazon have blocked mautic from sending the rest of the emails?

I really cant tell if all those 2069 contacts got my email

After several hours, Amazon SES now displays the correct amount of sent emails.

I still have a question though. Since my SES maximum send rate is 14, I should be using

mautic:messages:send --batch=13

Right? I couldn’t tell from the documentation if that command also supports the --batch parameter

Hi, batch means something else…
Here are the options:

Limit number of messages sent at a time. Defaults to value set in config.
Limit the number of seconds per batch. Defaults to value set in config.
By default, failed messages older than the --recover-timeout setting will be attempted one more time then deleted if it fails again. If this is set, sending of failed messages will continue to be attempted.
Sets the amount of time in seconds before attempting to resend failed messages. Defaults to value set in config.
Sets the amount of time in seconds before deleting failed messages. Defaults to value set in config.
Set name of lock to run multiple mautic:emails:send command at time
-f, --force
Force execution even if another process is assumed running.
Bypass locking.
-t, --timeout=TIMEOUT
If getmypid() is disabled on this system, lock files will be used. This option will assume the process is dead after the specified number of seconds and will execute anyway. This is disabled by default. [default: false]
-x, --lock_mode=LOCK_MODE
Allowed value are “pid” , “file_lock” or “flock”. By default, lock will try with pid, if not available will use file system [default: “pid”]
-h, --help
Display this help message
-q, --quiet
Do not output any message
-V, --version
Display this application version
Force ANSI output
Disable ANSI output
-n, --no-interaction
Do not ask any interactive question
-e, --env=ENV
The Environment name. [default: “prod”]
Switches off debug mode.
-v|vv|vvv, --verbose
Increase the verbosity of messages: 1 for normal output, 2 for more verbose output and 3 for debug

Probably you won’t exeed 14/sec, you would need a powerful server for that.
If you want to send max 14 / sec, limit your –message-limit=840 and run it every minute.

Are most of args available for all cron commands?

Also, no I’m actually not running any of these cron jobs every minute.

So far I’ve been running mautic:broadcasts:send --batch=13 every 5 minutes, which i see is needed for broadcast emails, then after that I guess mautic:messages:send runs to send out those 13 emails that were just taken from the broadcast batch?

So really the final limit argument; so as to not go against my SES limit, should really be set on mautic:messages:send ?

From the docs this is what it says about the -batch flag on broadcast emails:

  • --batch=X controls how many emails processed in each batch. This can be different for every provider. For example, Mautic has API connection to SparkPost. Their API can send - at present - 1000 emails per call. Therefore the batch should be 1000 for the fastest sending speed with this provider. Many SMTP providers can’t handle 1000 emails in one batch, so this would need to be lower.

It specifically talks about services not being able to “handle” the requests, by that I took to mean services not “willing” to handle the requests, which in this case is 14 per second for my SES account

You can get all arguments when you run --help

This is how email sending works:

The broadcast command ‘prepares’ the emails, the ‘send’ command actually sends them out from spool. (If you use filesystem queue)

1 Like