One more 4.0 release notes update

release-notes/4.0.0.md

@@ -1,6 +1,6 @@
-## RabbitMQ 4.0.0-beta.7
+## RabbitMQ 4.0.0-rc.1
 
-RabbitMQ `4.0.0-beta.7` is a preview of a new major release.
+RabbitMQ `4.0.0-rc.1` is a preview of a new major release.
 
 Starting June 1st, 2024, community support for this series will only be provided to [regularly contributing users](https://github.com/rabbitmq/rabbitmq-server/blob/main/COMMUNITY_SUPPORT.md) and those who hold a valid [commercial support license](https://tanzu.vmware.com/rabbitmq/oss).
 
@@ -51,11 +51,12 @@ This limit is necessary to protect nodes from consumers that run into infinite f
 consumers can drive a node out of disk space by making a quorum queue Raft log grow forever without allowing compaction
 of older entries.
 
-If 20 deliveries per message is a common scenario for a queue, a dead-lettering target must be configured
+If 20 deliveries per message is a common scenario for a queue, a dead-lettering target or a higher limit must be configured
 for such queues. The recommended way of doing that is via a [policy](https://www.rabbitmq.com/docs/parameters#policies).
+See the [Position Messaging Handling](https://www.rabbitmq.com/docs/next/quorum-queues#poison-message-handling) section
+in the quorum queue documentation guide.
 
-The limit can be [increased](https://www.rabbitmq.com/docs/next/quorum-queues#poison-message-handling) using a policy.
-This option is recommended against: usually the presence of messages that have been redelivered 20 times or more suggests
+Mote that increasing the limit is recommended against: usually the presence of messages that have been redelivered 20 times or more suggests
 that a consumer has entered a fail-requeue-fail-requeue loop, in which case even a much higher limit
 won't help avoid the dead-lettering.