mention AUTH as the solution to spam on NIP-17/59.

17.md

@@ -171,6 +171,10 @@ This NIP offers the following privacy and security features:
 
 The main limitation of this approach is having to send a separate encrypted event to each receiver. Group chats with more than 100 participants should find a more suitable messaging scheme.
 
+## Spam
+
+Spam is a known problem in encrypted messaging. Since the inner events are unsigned and wrapped in gift wraps with random keys, relays cannot apply traditional anti-spam based on pubkey reputation. The recommended approach for spam mitigation is described in the [Spam Protection section of NIP-59](59.md#spam-protection).
+
 ## Examples
 
 This example sends the message `Hola, que tal?` from `nsec1w8udu59ydjvedgs3yv5qccshcj8k05fh3l60k9x57asjrqdpa00qkmr89m` to `nsec12ywtkplvyq5t6twdqwwygavp5lm4fhuang89c943nf2z92eez43szvn4dt`.

59.md

@@ -77,6 +77,10 @@ needed to route the event to its intended recipient, including the recipient's `
 Encryption is done following [NIP-44](44.md) on the JSON-encoded event. Place the encryption payload in the `.content`
 of the wrapper event (either a `seal` or a `gift wrap`).
 
+## Spam Protection
+
+Gift wrap events are signed by random one-time keys, so relays cannot rely on pubkey-based anti-spam or anti-sybil measures (e.g. reputation, trust scores, rate limits by key). To mitigate this, a relay may enforce a [NIP-42](42.md) `auth-required` policy and authenticate clients before accepting gift wraps. Therefore clients SHOULD support authenticating to such relays using the user's real identity. Because NIP-42 authentication is ephemeral (it is not recorded in the event signature), it does not fully undermine the privacy or deniability properties of gift wrapping.
+
 ## Other Considerations
 
 If a `rumor` is intended for more than one party, or if the author wants to retain an encrypted copy, a single