Knowledge base
log-fileGlobalset by the HubDirectiveThe path to the log file; the line is mandatory, and it also sets the location of the monitor and SNMP logs.log-auto-rotationGlobalDirectiveThe switch for daily log file rotation; on by default.log-commands<source>set by the HubDirectiveWrites the full exchange of commands and responses to the log; the vendor calls this the first step when investigating connectivity.log-disabled-ips<domain>DirectiveThe only source of history: the list of disabled addresses shows “now,” the log shows “what happened.”log-rotateGlobalDirectiveThe number of files, including the current one; the default is eight, and zero turns rotation off entirely.dummy-smtp-await-slotGlobalDirectiveWait for a slot or reply 421 at once — and 421 changes the behavior of the sending side.dummy-smtp-ipGlobalDirectiveA local address keeps the black hole inside the machine; an external one opens it to the network.dummy-smtp-latencyGlobalDirectiveZero by default — and with zero the run measures the wrong thing: a real receiver never answers instantly.dummy-smtp-portGlobalDirectiveThe default of zero means “do not listen”: until the port is set, there is no mechanism.log-connections<source>set by the HubDirectiveWrites a log line when a connection from this source opens and closes; off by default.log-data<transmissions-api>DirectiveMore detailed logging than the submission API request log; off by default.log-data<source>set by the HubDirectiveRecords the exchange byte by byte, in hexadecimal and as text at the same time; the most detailed and heaviest level.log-inbound-proxy<smtp-listener>DirectiveWrites the received PROXY header to the log; works only with reception of such a header enabled.log-match-info<email-patterns>DirectiveWrites to the log the name of the pattern file that matched the parsed report; off by default.log-requests<transmissions-api>DirectiveWrites to the log the fact of every Transmissions API request; off by default.log-resolution<domain>DirectiveWrites to the log the course of name and route lookup for the receiver; off by default.log-tls<source>DirectiveDetails of encryption negotiation with the submitting client, in the node log; the default is not to record.log-tls<transmissions-api>DirectiveThe switch for detailed logging of encryption negotiation when handling HTTP API requests; off by default.log-transfer-failures<domain>set by the HubDirectiveWrites a warning when the connection breaks while headers and body are being transferred; off by default.log-verbose<signals>DirectiveAdds messages about the export of events to SparkPost Signals to the log; off by default.trace-dkim-check<source>DirectiveA trace of signature verification: queries for the public key travel with the message.trace-iprev-check<source>DirectiveThe trace travels with the message; for the reverse check it is short, but its nature is the same.trace-spf-check<source>DirectiveA debugging switch: everything the node asked DNS goes into the message.http-log-dataGlobalDirectiveMore detailed logging than the request log; off by default.http-log-requestsGlobalDirectiveA switch for logging calls to the management interface; off by default.http-log-tlsGlobalDirectiveA switch for detailed logging of encryption negotiation in the monitor log; off by default.log-hires-timestampGlobalDirectiveAdds milliseconds to log timestamps; off by default.Recipient eventscriticalMechanismThe last 50 delivery, bounce and deferral events per queue — enabled with track-recipient-events and visible in queue output.A fake receiver inside the node itselfMechanismThe node listens on its own port and pretends to be someone else’s server: messages go nowhere, but the load is real.Figure out why a queue to one receiver is growingProcedureFirst check the route and reachability with one command, then make the node attempt delivery with the session logged, and only for an intermittent problem enable per-receiver logging.Investigating a startup failureProcedureThe order of looking for the cause when the engine does not come up: the separate startup error file, the main log, a console run with output to the screen.What to do after a crashProcedureThe procedure after a crash: make sure the watchdog brought the engine back up, keep the report email, find the crash dump, pass it to the vendor.Troubleshooting mail receptionProcedureThe troubleshooting procedure when messages are not accepted: enable connection and command logging for the source, look at the session, turn it back off.traceCommandOpens a connection to a domain and tries to deliver one message from the queue, writing the SMTP conversation to the log.pmtad –debugCommandStarts the engine in the foreground, printing messages to the screen instead of a file.Where the node writes why it did not startFileA separate file with the startup failure message — the first thing to read when the engine does not come up after installation or a configuration edit.Crash dumpFileAn image of the engine’s memory saved at the moment of the crash.