we get rid of a couple of markdownlint issues with this. we'll use
fenced code blocks in order to have syntax highlighting: that should
make it a bit easier to read in the rendered version.

I also changed the point about keeping the psql session open as a
sub-point since it's not really something that needs to be explicitly
done. so the list is one point shorter now.

service/lists.md

@@ -246,12 +246,12 @@ send an email containing with a random string to the requester to prove that the
 control the email address.
 
 Secondly, the redaction request must be precise and not overly broad. For
-example, redacting all instances of "Joe" from the mail archives would 
-not be acceptable.
+example, redacting all instances of "Joe" from the mail archives would not be
+acceptable.
 
 Once all that is established, the actual redaction can proceed.
 
-If the requests is limited to one or few messages, then the first compliance
+If the request is limited to one or few messages, then the first compliance
 option would be to simply delete the messages from the archives. This can be
 done using an admin account directly from the web interface.
 
@@ -265,13 +265,13 @@ Such "surgical" redaction is done using SQL statements against the `mailman3`
 database directly, as mailman doesn't offer any similar compliance mechanism.
 
 In this example, we'll pretend to handle a request to redact the name "Foo Bar"
-and an associated email address, "foo@bar.com":
+and an associated email address, `foo@bar.com`:
 
  0. Login to `lists-01`, run `sudo -u postgres psql` and `\c mailman3`
 
  1. Backup the affected database rows to temporary tables:
 
-```
+    ```sql
     CREATE TEMP TABLE hyperkitty_attachment_redact AS
     SELECT * FROM hyperkitty_attachment
     WHERE
@@ -302,6 +302,7 @@ CREATE TEMP TABLE user_redact AS
 
  2. Run the actual modifications inside a transaction:
 
+    ```sql
     BEGIN;
 
     -- hyperkitty_attachment --
@@ -390,18 +391,19 @@ CREATE TEMP TABLE user_redact AS
     UPDATE "user"
         SET display_name = '[REDACTED]'
         WHERE display_name = 'Foo Bar';
+    ```
 
  3. Look around the modified tables, do `COMMIT;` if all good, otherwise `ROLLBACK;`
+    * Ending the `psql` session discards the temporary tables, so keep it open
 
- 4. Ending the `psql` session discards the temporary tables, so keep it open
+ 4. Look at the archives to confirm that everything is ok
 
- 5. Look at the archives if everything is ok
- 
- 6. End the `psql` session
+ 5. End the `psql` session
 
 To rollback changes after the transaction has been committed to the database,
 using the temporary tables:
 
+```sql
 UPDATE hyperkitty_attachment hka
         SET content = hkar.content
         FROM hyperkitty_attachment_redact hkar WHERE hka.id = hkar.id;
@@ -424,6 +426,7 @@ using the temporary tables:
 UPDATE "user" u
         SET display_name = ur.display_name
         FROM user_redact ur WHERE u.id = ur.id;
+```
 
 The next time such a request occur, it might be best to deploy the
 above formula as a simple "noop" Fabric task.