Formatting changes.

2026-09-12 13:32:13 +00:00 · 2026-07-07 09:16:13 -04:00
parent 24202ae4d7
commit cdabd937c7
28 changed files with 83 additions and 71 deletions
@@ -2,7 +2,7 @@

 One advantage of horizontal scaling in virtualized environments is that resources can be conserved by scaling the KumoMTA cluster up and down in response to sending patterns.

-!!!Note
+!!! note
    Auto-scaling is a complicated subject that is not recommended except for those with extensive experience in autoscaling technologies. For most senders, the predictable daily sending patterns are adequate for scheduling scaling, with alerting when the cluster size is too small.

 The most common install approach for scaling clusters involves Docker. For examples on deploying more advanced docker architectures, see [https://github.com/KumoCorp/kumomta/tree/main/examples](https://github.com/KumoCorp/kumomta/tree/main/examples).
@@ -69,8 +69,8 @@ BadDomain = [
 {% endcall %}

 Users can create their own classification rules file by copying the default
-file, editing it, and adding the path to their custom rules file to the *files*
-option in the **kumo.configure_bounce_classifier** function call. Each defined
+file, editing it, and adding the path to their custom rules file to the `files`
+option in the `kumo.configure_bounce_classifier` function call. Each defined
 rules file will be merged into the full ruleset.

 For additional information, see the [reference manual page on bounce
@@ -19,9 +19,9 @@ For more information on Feedback Loops and how to apply for them, see

 By default, KumoMTA will include a supplemental tracking header that will be
 extracted as part of the ARF message processing. This setting is controlled by
-the *supplemental_header* option in the **kumo.start_esmtp_listener** function.
+the `supplemental_header` option in the `kumo.start_esmtp_listener` function.
 Additional metadata can be preserved by listing the metadata keys desired in
-the *include_meta_names* argument.
+the `include_meta_names` argument.

 ```lua
 kumo.start_esmtp_listener {
@@ -22,7 +22,7 @@ For multiple log files, the `configure_local_logs` function can be called
 multiple times with different parameters.

 <!-- prettier-ignore -->
-!!!note
+!!! note
    Logs can also be published as webhooks. See the [Publishing Log Events Via Webhooks](../operation/webhooks.md) chapter.

 ## OS Considerations
@@ -200,7 +200,7 @@ end)
 ```

 Note that the example above does not have any handling for an empty or
-incorrect **X-Tenant** header.
+incorrect `X-Tenant` header.

 ## Throttling The Scheduled Queue

@@ -85,7 +85,7 @@ for more information.

 ## Provisioning Egress Sources Using Lua

-!!!note
+!!! note
    Most users will be satisfied with using the policy helper shown above.
    This section and the remainder of this page is for more advanced users.
    **The examples show here are illustrative: if all you intend is to copy
@@ -98,7 +98,7 @@ particular protocol. While the most common use case is an IP address used for
 SMTP, it could also define a specific outbound port for sending through
 port-based NAT, or a specific configuration for sending over HTTP.

-An Egress Source is defined using the **`kumo.make_egress_source`** function,
+An Egress Source is defined using the `kumo.make_egress_source` function,
 called during the init event. For more information, see the
 [make_egress_source](../../reference/kumo/make_egress_source/index.md) chapter of the
 Reference Manual.
@@ -159,7 +159,7 @@ end)

 ## Provisioning Egress Pools Using Lua

-!!!note
+!!! note
    Most users will be satisfied with using the policy helper shown above.
    This section and the remainder of this page is for more advanced users.
    **The examples show here are illustrative: if all you intend is to copy
@@ -173,7 +173,7 @@ default, with weighted round-robin available as an option.

 A given Egress Source can be added to multiple Egress Pools.

-Egress Pools are defined using the **`kumo.make_egress_pool`** function, called
+Egress Pools are defined using the `kumo.make_egress_pool` function, called
 during the `get_egress_pool` event:

 ```lua
@@ -8,7 +8,7 @@ KumoMTA supports multiple message spooling options.

 There are two kinds of spool storage possible, detailed below.

-!!!note
+!!! note
    We recommend that most users deploy using **RocksDB**.

 ## LocalDisk
@@ -21,7 +21,7 @@ maximum performance. If SSD drives are not used, 15K RPM disks are
 recommended. When using disk spooling, we recommend using ext4 with the
 *noatime* flag.

-```text
+```txt
 LABEL=/var/spool/kumomta/data /var/spool/kumomta/data ext4 rw,noatime,barrier=0 0 2
 ```

@@ -1,6 +1,6 @@
 # Configuring Traffic Shaping

-!!!note
+!!! note
    This page has moved. Traffic Shaping is now its own chapter in the User Guide.

    * [Traffic Shaping Overview](../trafficshaping/index.md)
@@ -37,19 +37,31 @@ File names and directory names are written like this: “The `simple-policy.lua`

 Character sequences are written like this: “To specify a wildcard, use the `‘%’` character.”

-When commands or statements are prefixed by a prompt, we use these:
+Commands that you type at a shell prompt are shown in a `console` code block, prefixed with a `$` prompt:

-```text
-$> type a command here
-#> type a command as root here
-kumo> type a KumoMTA CLI command here
+```console
+$ type a command here
 ```

+Commands that must be run with elevated privileges are shown using `sudo`:
+
+```console
+$ sudo type a command as root here
+```
+
+KumoMTA command-line tools, such as `kcli`, are also invoked from the shell prompt:
+
+```console
+$ kcli type a KumoMTA CLI command here
+```
+
+Where it is useful to show the result of a command, the output either follows the command in the same block or appears in an adjacent `txt` block.
+
 Commands are issued in your command interpreter. On Unix, this is typically a program such as sh, csh, or bash.

-!!!
-    When you enter a command or statement shown in an example, do not type the
-    prompt shown in the example.
+!!! note
+    When you enter a command shown in an example, do not type the `$` prompt
+    shown in the example.

 In syntax descriptions, square brackets (“\[” and “\]”) indicate optional words or clauses. For example, in the following statement, --user is optional:

@@ -41,7 +41,7 @@ This key must be appended to the Email Protection configuration file.

 To connect to a **Hornetsecurity Email Protection** service use `hornethost = hornet:connect(host, params)` in the top level of init.lua.

-```
+```txt
 Inputs:
  host: Hornet Service hostname or IP address (string)
  params: Array of options including
@@ -62,7 +62,7 @@ These API functions are not necessary and are not directly supported within Kumo
 To scan a message, use `result = hornet:scan(hornethost,extraparams,msg)` in any event that can access the full message content. EG: `smtp_server_message_received`

 Note that `hornet:connect` must be called prior to `hornet:scan`.
-```
+```txt
 Inputs:
  hornethost: Hornet service host object
  extraparams: Table of:
@@ -77,7 +77,7 @@ IE: "200 OK: {"state":1,"score":250,"verdict":"spam:low","spamcause":"gggr...omh

 If the extra parameter `addheaders` = `true`, then the scan result headers will be added directly to the message before delivery.

-```
+```txt
 IE:
 X-Hornet-spamcause: gggr...omh
 X-Hornet-verdict: malware
@@ -21,7 +21,7 @@ You will need sudo access to perform these changes.  Start by creating a service
 `sudo vi /etc/systemd/system/kumoproxy.service`

 Populate it with:
-```console
+```txt
 [Unit]
 Description=KumoMTA SOCKS5 Proxy service
 After=syslog.target network.target
@@ -44,7 +44,7 @@ Next, create an environment file where you can add your system variables.
 Populate with your IP and Port

 IE:
-```console
+```txt
 PROXY_IP="172.31.37.164"
 PROXY_PORT="5000"
 ```
@@ -6,7 +6,7 @@ segmented by a combination of size/time and stored in compressed files named
 after the time that the segment was started. To read these, you need to unpack
 them first. You have many options for configuring logging.

-```
+```txt
 /var/log/kumomta
 ├── 20230311-033705
 ├── 20230311-033844
@@ -26,7 +26,7 @@ kumo.on(
 )
 ```

-!!!warning
+!!! warning
    The above example would add AUTH credentials to every outbound connection. In production, this should be selectively applied based on the destination host or domain.

 See the [make_egress_path](../../reference/kumo/make_egress_path/index.md) section of the Reference Manual for more information.
@@ -98,7 +98,7 @@ page of the Reference Manual for more information.

 An example HAProxy server config is as follows:

-```
+```txt
 global
    log stdout  format raw  local0  debug

@@ -21,7 +21,7 @@ KumoMTA will accept any SMTP injection from the local host as well as any hosts
 in the 10.5.1.0/24 CIDR block on port 25.  The most basic form of "injection"
 is to test from localhost using nc or telnet.

-```
+```txt
 ehlo moto
 mail from:youremail@address.com
 rcpt to:youremail@address.com
@@ -8,7 +8,7 @@ $ sudo systemctl status kumomta

 The result should look something like this:

-```
+```txt
 kumomta.service - KumoMTA SMTP service
     Loaded: loaded (/lib/systemd/system/kumomta.service; enabled; vendor preset: enabled)
     Active: active (running) since Thu 2023-04-27 22:59:06 MST; 10h ago
@@ -2,7 +2,7 @@

 There are several things that can go wrong, especially when first installing KumoMTA. This page is intended to help with troubleshooting common issues.

-!!!Note
+!!! note
    There are multiple ways to get help with KumoMTA, see the [How To Get Help](../general/get_help.md) page for more information.

 ## Validate Your Configuration
@@ -55,7 +55,7 @@ When providing a stack trace you should also provide the output of `kumod --vers
 KumoMTA logs to the system journal for all error and status messages during operation, to view the log entries use journalctl:

 ```console
-[root@localhost ~]# journalctl -f -n 50 -u kumomta.service
+$ sudo journalctl -f -n 50 -u kumomta.service
 Oct 19 21:52:59 localhost systemd[1]: Started KumoMTA SMTP service.
 Oct 19 21:53:00 localhost.localdomain kumod[902]: 2023-10-20T01:53:00.328546Z  INFO localset-0 kumod: NodeId is 2a32fb9b-7353-48bd-a06e-cc97e224c924
 Oct 19 21:53:00 localhost.localdomain kumod[902]: 2023-10-20T01:53:00.337267Z  INFO localset-0 kumo_server_common::http_server: http listener on 127.0.0.1:8000
@@ -64,15 +64,15 @@ Oct 19 21:53:01 localhost.localdomain kumod[902]: 2023-10-20T01:53:01.221127Z  I
 Oct 19 21:53:01 localhost.localdomain kumod[902]: 2023-10-20T01:53:01.221509Z  INFO localset-0 kumo_server_common::start: initialization complete
 ```

-In this example the **-f** option tells journalctl to follow the log, in other words to tail or continuously read the file, the **-n 50** option tells journalctl to start by reading the previous 50 lines, and the **-u** option tells journalctl to filter by a specific unit, in this case the *kumomta.service* unit.
+In this example the `-f` option tells journalctl to follow the log, in other words to tail or continuously read the file, the `-n 50` option tells journalctl to start by reading the previous 50 lines, and the `-u` option tells journalctl to filter by a specific unit, in this case the `kumomta.service` unit.

-A common issue with new installs is ownership of the spool directory. When the spool is provisioned as a separate volume, it will not be owned by the **kumod** user. In this example we change ownership of the */var/spool/kumomta* directory, then attempt to start the kumomta service, then read the system journal to identify the issue:
+A common issue with new installs is ownership of the spool directory. When the spool is provisioned as a separate volume, it will not be owned by the `kumod` user. In this example we change ownership of the `/var/spool/kumomta` directory, then attempt to start the kumomta service, then read the system journal to identify the issue:

 ```console
-[root@localhost spool]# systemctl stop kumomta
-[root@localhost spool]# chown -R root /var/spool/kumomta/
-[root@localhost spool]# systemctl start kumomta
-[root@localhost spool]# journalctl -f -n 50 -u kumomta.service
+$ sudo systemctl stop kumomta
+$ sudo chown -R root /var/spool/kumomta/
+$ sudo systemctl start kumomta
+$ sudo journalctl -f -n 50 -u kumomta.service
 Oct 19 22:09:06 localhost.localdomain systemd[1]: Started KumoMTA SMTP service.
 Oct 19 22:09:06 localhost.localdomain kumod[5356]: 2023-10-20T02:09:06.752782Z  INFO localset-0 kumod: NodeId is 2a32fb9b-7353-48bd-a06e-cc97e224c924
 Oct 19 22:09:06 localhost.localdomain kumod[5356]: 2023-10-20T02:09:06.755699Z  INFO localset-0 kumo_server_common::http_server: http listener on 127.0.0.1:8000
@@ -103,7 +103,7 @@ Sometimes the default logging level will not expose sufficient information to tr

 To increase the verbosity of the logs written to the system journal, use the
 [kumo.set_diagnostic_log_filter](../../reference/kumo/set_diagnostic_log_filter.md)
-function in your `init.lua`` policy's **init** event handler:
+function in your `init.lua` policy's `init` event handler:

 ```lua
 kumo.on('init', function()
@@ -123,14 +123,14 @@ In addition, you can adjust the log filter level dynamically using [the HTTP
 API](../../reference/http/kumod/api_admin_set_diagnostic_log_filter_v1_post.md):

 ```console
-curl -i 'http://localhost:8000/api/admin/set_diagnostic_log_filter/v1' \
+$ curl -i 'http://localhost:8000/api/admin/set_diagnostic_log_filter/v1' \
    -H 'Content-Type: application/json' \
    -d '{"filter":"kumod=debug"}'
 ```

 This will produce output similar to the following:

-```console
+```txt
 Oct 20 09:26:43 localhost.localdomain systemd[1]: Started KumoMTA SMTP service.
 Oct 20 09:26:44 localhost.localdomain kumod[6061]: 2023-10-20T13:26:44.030934Z  INFO localset-2 kumod: NodeId is 2a32fb9b-7353-48bd-a06e-cc97e224c924
 Oct 20 09:26:44 localhost.localdomain kumod[6061]: 2023-10-20T13:26:44.032892Z  INFO localset-2 kumod::smtp_server: smtp listener on 0.0.0.0:25
@@ -167,5 +167,5 @@ The log levels available, in order from least to most verbose are:
 * Debug
 * Trace

-!!!warning
-    The lower, more verbose levels of log levels can be very verbose, especially the  **trace** level. These levels should not be enabled permanently as they can lead to a full disk in a short period of time.
+!!! warning
+    The lower, more verbose levels of log levels can be very verbose, especially the  `trace` level. These levels should not be enabled permanently as they can lead to a full disk in a short period of time.
@@ -42,12 +42,12 @@ log_hooks:new_json {
 }
 ```

-!!!Warning
+!!! warning
    The call to `new_json` must appear before the queues helper for it to work
    properly. See the [Example Config](../configuration/example.md) to see a
    working layout for the `init.lua` file.

-!!!Warning
+!!! warning
    The default traffic shaping rules that are likely present in your [Shaping Helper](../trafficshaping/shapingfiles.md) configuration will also affect messages queued for delivery via webhooks. To avoid issues, add throttle configuration specific to your webhook queue (based on the name provided when creating a webhook):

 ```toml
@@ -48,7 +48,7 @@ log_hooks:new_json {
 }
 ```

-!!!note
+!!! note
    In the preceding example we use the `meta` option instead of the `headers` option because logging headers requires the message body to be processed during logging. This can be combined with the [msg:import_x_headers](../../reference/message/import_x_headers.md) function to push the relevant headers into the message metadata for efficient logging.

 Given the log hook name of `webhook` the following should be added to the shaping helper TOML configuration file:
@@ -37,7 +37,7 @@ graph TD

  * A log entry will be generated for the message reception event. 

-!!! Note 
+!!! note
    If you have configured [log hooks](../operation/webhooks.md) or routing logs via [AMQP](../policy/amqp.md) or [Kafka](../policy/kafka.md) then a message will be queued for each log entry that needs to be routed. This means that each message injected will result in multiple messages in the queues (at least one message for the Received log entry and one for the Delivered log entry).

 2) The message is assigned into a Scheduled Queue based on the combination of its **campaign,** **tenant,** and destination **domain**. If there is no defined campaign or tenant, the message is placed in a queue based on the elements that are present.
@@ -36,14 +36,14 @@ sudo systemctl edit --full kumomta.service
 You should disregard everything except the `[Service]` section.
 At the bottom of that section, add 2 lines:

-```
+```txt
 Environment=VAULT_ADDR='http://<YOUR_SERVER_LOCATION>:8200'
 Environment=VAULT_TOKEN='<YOUR_ACCESS_TOKEN>'
 ```

 When done, it should look something like this:

-```
+```txt
 [Unit]
 Description=KumoMTA SMTP service
 After=syslog.target network.target
@@ -103,7 +103,7 @@ Vault has a number of advantages over statically storing secrets. Aside from the

 Another advantage is being able to dynamically load keys on demand. This can be very helpful with DKIM key rotation. With the keys stored within the vault, they can be loaded as-needed when messages pass through the server that need a particular key:

-```Lua
+```lua
 local vault_signer = kumo.dkim.rsa_sha256_signer {
  key = {
    vault_mount = 'secret',
@@ -4,7 +4,7 @@ Some sending environments use a mixture of different services to send messages,

 The following example shows how to send a queued message via custom lua, in this case assembling an API call and sending it to a third-party SMTP API relay provider.

-!!!warning
+!!! warning
    Storing credentials as hardcoded values in a policy script such as this is not recommended, instead, use the built-in Secrets Load function. See [https://docs.kumomta.com/reference/kumo.secrets/load/](https://docs.kumomta.com/reference/kumo.secrets/load/).

 ```lua
@@ -2,7 +2,7 @@

 When hosting relay users it is important to protect your infrastructure from malicious senders, often without the ability to whitelist the IP addresses of legitimate users. In such environments, it is critical to setup SMTP Authentication to validate injecting hosts before relaying their mail.

-!!!note
+!!! note
    Authentication in KumoMTA can only occur on a TLS protected connection after `STARTTLS` has successfully been processed. This is because AUTH PLAIN credentials can be decoded and should not be sent over an open connection.

 ## Checking Authentication Against a Static User Table
@@ -51,7 +51,7 @@ kumo.on('smtp_server_auth_plain', function(authz, authc, password)
 end)
 ```

-!!!warning
+!!! warning
    To prevent blocking when checking data like AUTH credentials we recommend using the [Memoize](../../reference/kumo/memoize.md) function to cache query results for future connections.

 ## Querying a Keystore for Authentication
@@ -91,4 +91,4 @@ egress_pool = 'pool-1'
 require_authz = ["daniel"]
 {% endcall %}

-This prevents users other than **daniel** (multiple users can be specified) from using the tenant for sending.
+This prevents users other than `daniel` (multiple users can be specified) from using the tenant for sending.
@@ -18,7 +18,7 @@ There are three configuration locations required to implement TSA:

 ## Configure Traffic Shaping In Your `init.lua` Server Policy

-!!!note
+!!! note
    It's easiest to reference the [Example Config](../configuration/example.md) to see how the complete configuration looks.

 The server's `init.lua` file will require modifications to enable it to be used with TSA.
@@ -41,7 +41,7 @@ local shaper = shaping:setup_with_automation {

 This section enabled communication with the TSA daemon. The publish and subscribe URLs correspond to the TSA daemon's HTTP listener endpoint defined in its tsa_init.lua.  For a single node deployment the values shown here are sufficient.  You may list multiple publish and/or subscribe endpoints to publish to multiple hosts and read shaping configuration from multiple hosts, respectively. In addition, while the `setup_with_automation` call is aware of the community shaping rules file, any custom file must be identified in the `extra_files` directive as seen in the example above.

-!!!warning
+!!! warning
    As mentioned previously, your rules merge with the other files listed unless a given block has `replace_base=true`. To fully remove the defaults provided by the KumoMTA team you need the following:

    ```lua
@@ -107,7 +107,7 @@ kumo.on('tsa_load_shaping_data', function()
 end)
 ```

-!!!note
+!!! note
    The `tsa_init.lua` has no implicit loading of the default `shaping.toml` file. To avoid loading the default file simply omit it.

 ## Writing Automation Rules to `shaping.toml`
@@ -18,7 +18,7 @@ will take precedence overall.
 You can specify `replace_base=true` in a block to have that block override the
 current set of accumulated values.

-!!!warning
+!!! warning
    There is currently no mechanism for unsetting an option previously merged in. If there is a throttle set earlier (for example in `[default]`) that you wish to unset rather than explicitly define a different throttle then you **must** use `replace_base=true` to replace all previously merged options.

 Most options merge directly over the top of earlier options, but the
@@ -2,9 +2,9 @@

 ## MX Rollups and Option Inheritance

-By default, shaping.lua treats each domain entry as applying to the site_name generated for that domain, and those settings apply to any destination domain that also maps to the site. If you need to explicitly override a setting for a destination domain without consideration for the site_name, you need to set the `mx_rollup` option to **false** when configuring the domain.
+By default, shaping.lua treats each domain entry as applying to the site_name generated for that domain, and those settings apply to any destination domain that also maps to the site. If you need to explicitly override a setting for a destination domain without consideration for the site_name, you need to set the `mx_rollup` option to `false` when configuring the domain.

-If you configure a domain that belongs to a configured site without setting the `mx_rollup` option to **false**, you will cause an error.
+If you configure a domain that belongs to a configured site without setting the `mx_rollup` option to `false`, you will cause an error.

 Consider the following example, with foo.com being a domain hosted by Yahoo!:

@@ -39,7 +39,7 @@ max_connection_rate = "100/min"
 max_message_rate = "100/s"
 {% endcall %}

-The *mx_rollup* option indicates whether or not the settings should apply to the domain or the site_name. In the example above, even though foo.com is hosted by Yahoo! we want to override the message throttle for the foo.com domain. The mx_rollup option is true by default and only needs to be specified for domains that override the main site name entry.
+The `mx_rollup` option indicates whether or not the settings should apply to the domain or the site_name. In the example above, even though foo.com is hosted by Yahoo! we want to override the message throttle for the foo.com domain. The `mx_rollup` option is true by default and only needs to be specified for domains that override the main site name entry.

 While the default max_deliveries_per_connection is 100, it is overridden for yahoo.com (and all domains that share the same site name as the yahoo.com domain) to 20. The foo.com domain is part of the same site name as yahoo.com, but because mx_rollup is set to false the foo.com domain is treated separately and instead is set to 50. Because there is a sources entry for IP-1, the max_deliveries_per_connection is further overridden to 5 for that source's traffic in particular.

@@ -57,9 +57,9 @@ You can configure this using a `provider` block in your shaping file(s).
 For an example, let's consider Microsoft. Microsoft hosts two different consumer email domains (Outlook and Hotmail) as well as Office 365. While the consumer domains are run on the same servers, they have two different MX patterns:

 ```console
-dig +short mx hotmail.com
+$ dig +short mx hotmail.com
 2 hotmail-com.olc.protection.outlook.com.
-dig +short mx outlook.com
+$ dig +short mx outlook.com
 5 outlook-com.olc.protection.outlook.com.
 ```

@@ -127,10 +127,10 @@ order to fully match a destination site against the provider.  The reason for
 this is to avoid pathologically weird situations when someone has a vanity
 domain that blends multiple different providers together.

-!!!note
+!!! note
    The suffix matching is *not* a regex operation, it is purely based on whether the string specified appears at the end of the MX or domain being tested. Do not use any wildcard characters.

-!!!warning
+!!! warning
    When a provider is defined, it does ***not*** merge the various `site_name` queues covered by the provider together, which means that the `connection_limit` and `max_message_rate` options will not be enforced across all matching queues, but will be applied separately to each ready queue covered by the provider block.

 The provider block introduces two new options: `provider_connection_limit` and `provider_max_message_rate`. When the `provider_connection_limit` and `provider_max_message_rate` options are set, the throttles defined will be enforced across all matching site_name ready queues for that provider. This is typically the desired behavior. One example of a scenario where the provider_ options would not be used is Mimecast: each regional MX pattern used by Mimecast is a separate set of servers in that region, but traffic shaping expectations are the same for all regions. To address this we use a provider block without the `provider_` throttles:
@@ -144,5 +144,5 @@ connection_limit = 10

 In this case we can define traffic shaping rules that apply to Mimecast globally, but which are still enforced by each region's ready queue without limiting worldwide traffic.

-!!!note
+!!! note
    Both the `provider_` and regular throttles can be set, where `connection_limit` would be for the individual site names, and `provider_connection_limit` would cap the overall connection count. The same would apply for `max_message_rate` and `provider_max_message_rate`. Combining the `provider_` and regular throttles should be done with care, as it easy to over-constrain the server if the settings are not aligned correctly.
@@ -23,7 +23,7 @@ For example: if a sender wanted to limit connections to 10 per domain, and Googl

 Messages in the Ready Queue are grouped into separate queues based on the combination of `egress_source` and `site_name`. The `routing_domain` is provided for convenience when working out what parameters to use.

-!!!note
+!!! note
    It is important to understand that while KumoMTA will build queues based on a `site_name`, it is not expected that the end user will configure traffic shaping using a `site_name`. Instead, configuration is done using a domain identifier that belongs to a given `site_name` and compare the generated `site_name` to it, as is done in the `shaping.lua` helper.

    For example, when using the helper to configure traffic shaping for the Yahoo! domains, a user would configure traffic shaping for `yahoo.com`, knowing that all domains that have a matching `site_name` would also have the same traffic shaping configuration applies.
@@ -58,7 +58,7 @@ trigger = {Threshold="2/hr"}
 duration = "2 hours"
 {% endcall %}

-As a special case, the domain can be named *default*, in which case those settings will apply globally. The global settings are superseded by the domain settings, which are superseded by the source settings.
+As a special case, the domain can be named `default`, in which case those settings will apply globally. The global settings are superseded by the domain settings, which are superseded by the source settings.

 The full set of available options is listed in the [kumo.make_egress_path](../../reference/kumo/make_egress_path/index.md) page of the Reference Manual.

@@ -98,7 +98,7 @@ local shaper = shaping:setup_with_automation {
 }
 ```

-!!!Note
+!!! note
    When a given scope is defined in multiple files, the more recently read file does not completely replace the configuration defined in the previous file, instead the options within that scope are merged.

 If you want to completely replace the information for a given block, you