Knowledge base
How delivery results leave a MailerQ nodecriticalmechanismResults are published to broker queues and removed by whoever reads them first — so collection is destructive, exclusive, and mandatory.clustercriticalWritten by the HubqueueThe fanout exchange over which nodes announce themselves and control messages travel.failurecriticalqueueMessages that have finally failed, with the full history of attempts that led there.outboxcriticalqueueThe one queue MailerQ reads. Everything to be sent — new mail, retries coming back, messages accepted over SMTP — arrives here.successcriticalqueueEvery successful delivery is published here as a full result object, and stays until somebody reads it.outbox+NNNNimportantqueueEleven queues where retries wait, each expiring into the next and finally back into the sending queue.to: domain (id)importantqueueCreated on the fly when a limit, a pause or greylisting holds mail back, and named after what is being held.(default exchange)Written by the HubqueueRabbitMQ's built-in exchange, where a routing key is simply a queue name — which is why MailerQ's routing keys read like queue names.inboxWritten by the HubqueueWhere mail accepted over SMTP is published — pointed at the sending queue by default, so accepted mail simply leaves.localWritten by the HubqueueWhere mail to addresses listed as local is published instead of being sent onward.reportsWritten by the HubqueueWhere incoming messages recognised as delivery or DMARC reports are published.retriesWritten by the HubqueueWhere notices about rescheduled attempts would be published — not configured on a stock node, and absent from ours.amq.gen-*queueThe anonymous queue each node binds to the cluster exchange to receive announcements.dsnqueueWhere generated delivery notifications are published; shipped pointing at the sending queue.refusedqueueWhere messages the SMTP server rejected would be kept, if anyone wanted them.unroutablequeueCatches messages an exchange could not route anywhere.