Knowledge base

Address suppression

entries in this scenario: 20
hashed-address<address-list>DirectiveThe address is lowercased, hashed with SHA256 and encoded as BASE64URL; the engine hashes the address being checked and compares the hashes.suppression-lists<source>DirectiveAttaches one or more named address lists; a recipient on a list is rejected at submission or bounced later, depending on how invalid recipients are accepted.suppression-lists<virtual-mta>DirectiveThe same line as in a source, but here there is no choice — the message is always accepted, queued and bounced.address<address-list>set by the HubDirectiveAccepts three forms — a full address, a bare local part or a regular expression in slashes.address-file<address-list>DirectiveIncludes a file where each line holds a full address or a bare local part.hashed-address-file<address-list>DirectiveIncludes a file where each line is the hash of a whole address; there is not a single readable address in the file.Two attachment points — and two different behaviorscriticalMechanismA list attached to a source rejects the recipient at submission or bounces the message later; attached to a sending address or pool, it always accepts and then bounces.The bounce category in accounting — configurable, not vendor-fixedcriticalMechanismThe bounceCat string in every accounting record comes from a pattern list that can be extended with your own rules and your own category names.Parsing bounces that arrive as messagescriticalMechanismBounce reports that arrive as messages are parsed by a separate processor — and it runs before the complaint processor.Configuration through the API and the file do not reconcilecriticalMechanismObjects created through the configuration interface cannot be edited in the file: two sources of truth about the configuration do not reconcile.Complaints parsed by the node — and they are parsed secondcriticalMechanismMail that arrives at an address from the configured list is parsed as a complaint report; the parsing order matters — the complaint processor runs after the bounce processor.Address lists — named and unnamedMechanismA list of addresses, domains, patterns or hashes; a named one is attached by directives such as suppression, an unnamed one lives inside an inbound mail processor.deletecriticalCommandDeletes recipients from the queue by selection; it does not run without –queue or –jobId.digestCommandComputes the hash of a given string with the chosen method.listCommandLists recipients in queues by selection; with –pause it interrupts a recipient’s delivery to show it.Address lists through the configuration APIcriticalAPI endpointCreates, reads, extends and deletes address and domain lists — for suppression, for example — without editing files.Permanently bouncedcriticalAccounting recordThe recipient permanently did not receive the message — either the receiving server refused for good, or the node itself bounced the message when the deadline expired.ComplaintAccounting recordA complaint report was received and parsed by the configured processor.Parsed bounce from outsideAccounting recordA bounce report email arrived at the configured processor and was parsed.Spam trapsMonitor screenThe SparkPost Signals report on spam trap hits by day — as a count or as a share of the day’s volume.