Automated Suspension of a pathway. #51
Comments
wez
added a commit
that referenced
this issue
Jun 23, 2023
These are two different groups of queues, so there are two different
sets of things to manage them.
kcli now has `suspend(-list|cancel)?` and
`suspend-ready-q(-list|cancel)?` subcommands for establishing a
suspension, listing the suspensions and cancelling a suspension
in the scheduled-q and ready-q namespaces respectively.
The names of the ready queues can be derived from the metrics API:
```console
$ curl -s 'http://localhost:8000/metrics.json' | jq .
...
"ready_count": {
"help": "number of messages in the ready queue",
"type": "gauge",
"value": {
"service": {
"smtp_client:source2->(in1-smtp|in2-smtp).messagingengine.com": 0.0
}
}
},
...
```
From the above, `source2->(in1-smtp|in2-smtp).messagingengine.com` is
the name of the underlying ready queue.
We can and probably should add something to `kcli` to make that slightly
easier to review and manage for the operator.
refs: #51
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
As a Deliverability Engineer, there are numerous responses I can encounter that are best addressed by suspending my traffic on a given pathway for a period of time.
One example of this is the common Yahoo TS04 error:
421 4.7.0 [TSS04] Messages from 0.0.0.0 temporarily deferred due to user complaints - 4.16.55.1; see https://postmaster.yahooinc.com/error-codesWhen such an error is encountered, the MTA needs to stop sending over that IP to the Yahoo MX group for two hours, as per Yahoo's recommendation.
The text was updated successfully, but these errors were encountered: