-
@mdreira oh I see, wouldn't it then also just work with throttling the mails sent from a mautic instance instead of making the mautic apps all just hand over thousands of mails to some queue? I may not fully get the use-case of the queue then, is the rabbitmq talking to the mail server then to act as some rate-limiting entity? I would expect something to be a consumer of that queue if various mautic instances throw mails into it. Maybe you can shed some more light how it is design to work, I am no marketing mail expert
-
@nebulon Before I comment further on this topic, I want to say something that will surely help you understand why we are actually asking this application in Cloudron.
Right now we are using Amazon SES to send the emails from each Mautic application. Amazon SES has its own queue server (SQS), so we don't urgently need Rabbitmq right now.
As we see a lot of potential in the development of the Cloudron mail server and all the improvements that are going to be made, we think it will be a perfect opportunity to test the Cloudron mail server with the Mautic applications and if it goes well ... to go off using Amazon SES with certain smaller clients.
If Cloudron Mail, together with the rest of the improvements, has a queue server like RabbitMQ that can be configured for all applications that send emails (Mautic, Mailtrain, Freescout, WP ...), the Cloudron mail server would be much more effective and would improve its performance. It could accept much larger volumes of mail.
Just like Amazon SES has a queue server, Cloudron Mail should have one.
I am seeing now that it has been a mistake of mine to request this application only for Mautic, when in fact it is an important improvement for Cloudron Mail. It should be in that section and the title of this post could be changed.
-
@mdreira Thanks for the explanation, I think I understand this feature request a bit better now. What you are desiring is two things - a) making the mail server accept more volumes of mail (if it doesn't already) and b) have a monitorable mail delivery queue. The issue is actually not RabbitMQ as such.
-
So actually from the Mautic documentation: "Processing. Once the queuing mechanism is activated, any page hits and email opens will be queued up to be processed later. To process them, you will need to run some console commands on a regular basis."
It seems to me the queue system for Mautic is not actually related to to email sending, but rather processing email opening or other analytics tasks, which are only stashed away in the queue until the server/mautic has time to process them further. In such a case a per-mautic rabbitmq would solve that just fine.
I feel like we need a better understanding of this first, before throwing in further components. This may or may not be beneficial if running the queue on the same machine.
-
Good catch. It indeed says "Use this if you are getting too much traffic at once from people opening pages or opening emails.". So , the queue is not for email processing, it's really for the callbacks (like 1 pixel images) in the email or if someone clicked on a link in the email.
-
@girish @nebulon Yes! As I wrote above in another comment, Mautic has integration with RabbitmQ to manage tracking hits queue (email openings or page openings), since Rabbitmq supports multiple messaging protocols.
This does not limit Rabbitmq to be used as an email queue server integrated with Cloudron Mail.
If RabbitMQ is integrated into Cloudron Mail, it could manage an orderly queue of all applications that send emails using Cloudron Mail (improving its efficiency and performance) with other benefits for Mautic.
Therefore, I would not install RabbitMQ with Mautic app, but as one more application in Cloudron, which automatically connects with Cloudron Mail, managing the Cloudron Mail queue.
This would make it possible for even another cloudron server that is only used as email server of all applications from other cloudron servers that have a lot of mail sending work (as Mautic). Rabbitmq could connect to different hosts.
-
@mdreira Just reading the docs a bit more, I am not unable to understand how it works.
It seems Mautic uses RabbitMQ to queue the mail instead of sending out the mail instantly. What's not clear is what happens next.
a) Does the mail server directly read from RabbitMQ?
b) Or does mautic read them from RabbitMQ and send to mail sever via SMTP? It seems it is the latter and one has to run
mautic:messages:sendjob to send emails.(If it's b, as a further question, I don't quite get what value the queue adds since all mail servers have a queue of their own anyway. What is the issue with mautic sending mails directly? Generally, a mail queue is useful when the email sending is to be made asynchronous. But isn't mail sending already async in mautic with cron jobs? AFAIK, mails are never sent immediately.)
-
@girish I'm going to try to explain how this would work according to our understanding, because we have never implemented Rabbitmq.
Mautic has a very simple mail queue system, whose sending works with a cronjob. More specifically with the cronjob: mautic:emails:send
Mautic is placing the messages to send within a directory that we set up, and when the cronjob starts, the messages are sent with the speed that we set up.
These settings are in the general Mautic configuration, Email settings section, queue settings: https://prnt.sc/12IL9N1
As you see, you can setup the directory path where you would leave the messages by sending (1), number of messages to be sent (2), time to send them (3) ...
With this, Mautic's workload is reduced a bit if you have thousands of emails to send (since they are being sent bit by bit), but still using Mautic resources with the cron, it does not keep in mind queues of others Mautic apps and delay emails sending.
What we think, is that in the part where the directory route is configured, we could put a directory that is controlled by Rabbitmq and at the same time Rabbitmq is integrated with Cloudron Mail.
We would leave empty the rest of the fields of the Mautic queue configuration that I showed you.
In this way, once Mautic puts the emails in queue, forget them. The Mautic cron "mautic:emails:send" is no longer needed and do not spend more resources, but it is Rabbitmq who manages the sending with Cloudron Mail.
And if we connect all Mautic apps to RabbitmQ, we can asynchronously manage the sending of all emails that are coming from each mautic app by sort and with the configuration we have set. Making the email sending faster and without using Mautic resources. We can also configure a queue of tracking hits, making everything even easier for Mautic.
Therefore, the first test that would have to be done is the integration of Rabbitmq with Cloudron Mail, so that the emails go through the queue before being sent by the mail server.
Then a directory would be configured in Mautic, and that directory in Rabbitmq.
If Cloudron Mail already has a queue system that we can configure by domain (sometimes we can want to prioritize queues of clients more than others) and sends the emails asynchronously, I think it is not necessary Rabbitmq.
The cronjobs do not make email sendings asynchronously at all, because all Mautic's applications have the cron configured in the same minutes of the day.
-
@mdreira Thanks for the detailed response!
I guess step 1 is to make the mail queue visible from the Cloudron Mail side and also have throttle/rate limits and then we have to take it from there. We use Haraka as our mail server and the closest it has for rate limits is http://haraka.github.io/plugins/rate_limit/ . There is no real queue management but there is a status plugin to somewhat monitor it and send commands - http://haraka.github.io/plugins/status/ . Have to look into these further.
-
M marcusquinn referenced this topic on
