Knowledge base
rabbitmq-failurecriticaldirectiveRouting key under which a message that has finally failed is published, with its full attempt history.rabbitmq-successcriticaldirectiveRouting key under which the result of every successful delivery is published.send-logcriticaldirectiveText log of every delivery attempt — the only record of intermediate attempts, which never reach the result queues.application-logimportantdirectiveWhere the engine reports its own state: start-up, database and broker connections, configuration reloads, crashes.send-log-formatimportantWritten by the HubdirectiveTemplate for each delivery line, with access to any field of the message and of the result, plus conditionals.www-portimportantWritten by the HubdirectiveTCP port the management console is served on, without encryption.rabbitmq-reportsWritten by the HubdirectiveWhere incoming messages recognised as reports — bounce notifications, DMARC reports — are published.received-logdirectiveText log of messages accepted by the built-in SMTP server.download-bin-logdirectiveCompact machine-readable copy of the download log.download-logdirectiveText log of resources the engine fetched from the internet while building messages.download-log-formatdirectiveTemplate for download lines; ships as a timestamp and the URL.message-tracingdirectiveTurns on detailed tracing of what happens to individual messages.received-bin-logdirectiveCompact machine-readable copy of the intake log.received-log-formatdirectiveTemplate for intake lines, addressing the incoming message JSON directly and guarding the message id with a conditional.send-bin-logdirectiveCompact machine-readable copy of the delivery log.www-cache-controldirectiveValue sent in the Cache-Control header for the console's static files.www-connectionsWritten by the HubdirectiveHow many HTTP connections the console will hold at once.www-dirdirectiveDirectory the console's HTML, JavaScript and translations are served from.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.Why the result object decides what analytics can saycriticalmechanismThe result is the job plus the attempt history — which means our analytics are limited by what we put into the job, not only by what the engine reports.Three counters that belong in a total and are not in onecriticalmechanismstrange is counted by nothing, unassignable by one total, expired and norecipients by the other — so no number on the screen is the count of failed messages.Where it stopped versus why it failedcriticalmechanismMailerQ classifies by stage, PowerMTA by cause, and Hub's analytics speak the second — so the states must be mapped before a MailerQ node can appear in the same charts.One number per counter, per second, per sliceimportantmechanismThe engine publishes a fixed array of twenty-four values every second for each slice of the address × domain × tag filter; everything else is arithmetic on top.The template language the log formats shareimportantWritten by the HubmechanismLog lines are rendered from templates with access to whole objects by path and with conditionals — so a log can carry anything a message or a result contains, including our own fields.Six places the interface says one thing and does anotherimportantmechanismA short list, all verified: a control that does nothing, a password in clear text, a list that does not refresh, a key that signs nothing, a hidden screen, and orphaned rows.What the engine does not sendimportantmechanismNine of the thirty-three counters exist only in the browser, with their arithmetic written in the console's own source.Record what a node is actually configured to doimportantprocedureSix readings that capture everything a node's behaviour depends on — and the baseline to restore it from.Mail goes in, nothing comes outimportantprocedureSeven readings in order, from the broker inwards — the sequence that found both real cases on the stand.failurecriticalqueueMessages that have finally failed, with the full history of attempts that led there.successcriticalqueueEvery successful delivery is published here as a full result object, and stays until somebody reads it.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.Log filesconsole screenLists the engine's log files and views them live, with a filter that speaks the same states and results as the delivery classification.SMTP monitorconsole screenWatches live SMTP conversations — the thing PowerMTA has no equivalent for.The dashboardconsole screenA rearrangeable wall of widgets over the same address × domain × tag filter as every other screen.The settings shellconsole screenThe frame that holds the sixteen settings sections, each a hash route of its own.Domain, address, pool, tag and remote address screensconsole screenFive screens showing the same statistics narrowed to one destination, one sending address, one pool, one tag or one receiving server.deliveriescriticalcounterMessages a receiver accepted — the one unambiguous number in the set.greylistedcriticalcounterTemporary refusals — the messages that will be tried again.allgreylistedimportantcounterEvery temporary refusal, whether from the receiver, from us, or inherited.attemptsimportantcounterAttempts started in this second — not results, and deliberately not the denominator of any rate.errorsimportantcounterPermanent SMTP refusals, plus connections lost mid-conversation.failuresimportantcounterEleven error counters added together — excluding unassignable and strange, both of which are real failures.noipsimportantcounterDestinations that resolved to nothing — the list problem, not ours.norecipientsimportantcounterJobs that arrived without a usable recipient — our bug, not the receiver's.parkedimportantcounterMessages moved out of memory into a temporary per-destination queue because a limit is holding them back.strangeimportantcounterThe engine's bucket for failures it cannot classify — and the only counter excluded from every total.successimportantcounterDeliveries over finished messages in this second — not over attempts.unassignableimportantcounterMessages with no usable sending address for their destination — a configuration failure that the main failure total leaves out.untriederrorsimportantcounterMessages failed without an attempt, because the engine already knew the attempt would fail.untriedgreylistedimportantcounterMessages deferred without an attempt, on the strength of a recent temporary refusal.allerrorscounterSeven error counters summed — permanent failures only, so it excludes expiries, missing recipients and everything greylisted.errorRatecounterThe complement of the success rate, over the same denominator.expiredcounterMessages that ran out of time rather than out of attempts.forcederrorscounterMessages we failed on purpose, permanently.forcedgreylistedcounterMessages we deferred on purpose with a temporary code.nobodycounterThe body could not be fetched from the message store, or personalisation failed.notsecurecounterMessages refused by our own TLS requirement, not by the receiver.queuecounterMessages the engine is holding, read from the broker and not yet finished.queuedcounterEverything the engine is holding — in memory, assigned or parked.totalErrorscounterHow much of the node's finished traffic this slice failed — a share, not a rate.totalSuccesscounterNot a success rate at all: how much of the whole node's finished traffic this slice accounts for.assignedcounterMessages waiting on a connection that is still being established.bytescounterThe volume actually handed to receiving servers.notification_subscriptionsdatabase tableBrowser subscriptions for the console's push notifications.(custom properties)criticalWritten by the Hubmessage propertyProperties MailerQ does not recognise are carried through untouched and returned in the result.tagscriticalWritten by the Hubmessage propertyFree-form labels that follow a message into statistics, logs, results and every interception mechanism.queuesimportantWritten by the Hubmessage propertyResult queue names for this message alone, overriding the node's success and failure.keepmimeWritten by the Hubmessage propertyWhether the full message is included in the result object published after delivery.(custom properties)criticalresult propertyProperties the job carried that MailerQ does not recognise come back untouched.descriptioncriticalresult propertyThe receiving server's response in its own words.fatalcriticalresult propertyWhether this outcome ends the message or leaves it to be retried.fromcriticalresult propertyThe local address the attempt was made from.individualcriticalresult propertyWhether the failure concerns this message alone or everything going to that destination.recipientcriticalresult propertyThe recipient address of the delivery.resultcriticalresult propertyOne of five outcomes — accepted, error, invalid, lost, timeout — the second half of the classification.resultscriticalresult propertyThe array of attempts, each with its own state, outcome, codes, addresses and timing — the heart of the result.statecriticalresult propertyThe stage of the delivery at which this attempt finished — the first half of MailerQ's failure classification.tagscriticalresult propertyThe labels the message carried, returned unchanged.codeimportantresult propertyThe numeric code the receiving server returned.greylistedimportantresult propertyWhether the receiver asked us to come back later rather than refusing.statusimportantresult propertyThe three-part extended status, more specific than the numeric code.timeimportantresult propertyThe moment this attempt produced its outcome.toimportantresult propertyThe address of the receiving server the attempt talked to.enveloperesult propertyThe envelope address the message was sent with.extractedresult propertyParsed pieces of the message — subject, from, to, and the header map.httpresult propertyFor messages injected over REST: which token submitted them and from which address.message-idresult propertyMailerQ's own identifier for the message, generated when the message has none.strangeresult propertyThe engine's marker for behaviour it could not classify.keepmimeresult propertyFlag showing whether the result carries the full message.sentresult propertyHow many bytes went over the connection and how many were message content.x-mq-tagcriticalemail headerAttaches a label; repeat the header for several.x-mq-results-queueimportantemail headerDirects this message's results to a named queue instead of the node's own.x-mq-failure-queueemail headerDirects failed results for this message to a named queue.x-mq-retry-queueemail headerDirects notices about rescheduled attempts for this message to a named queue.x-mq-success-queueemail headerDirects successful results for this message to a named queue.x-mq-keepmimeemail headerIncludes the full message in the published result.The content was judgedcriticaldelivery stateThe verdict after the whole message was transferred — the state a successful delivery also carries.The recipient was refusedcriticaldelivery stateThe receiver refused the recipient address — unknown, full, disabled — before any content was sent.Processing the jobimportantdelivery stateThe job itself could not be processed — malformed, incomplete or otherwise unusable.Unclassifieddelivery stateThe engine could not place the failure in any stage.Deliveredcriticaldelivery resultThe receiver accepted the message.Refusedcriticaldelivery resultSomething refused the message, and said so.No answerimportantdelivery resultThe receiver went silent rather than answering.