Merge pull request #1625 from matrix-org/erikj/auth_rejections

Explain how to handle rejected events

specification/server_server_api.rst

@@ -360,17 +360,6 @@ be inserted. The types of state events that affect authorization are:
 - ``m.room.power_levels``
 - ``m.room.third_party_invite``
 
-Servers should not create new events that reference unauthorized events.
-However, any event that does reference an unauthorized event is not itself
-automatically considered unauthorized.
-
-Unauthorized events that appear in the event graph do *not* have any effect on
-the state of the room.
-
-.. Note:: This is in contrast to redacted events which can still affect the
-          state of the room. For example, a redacted ``join`` event will still
-          result in the user being considered joined.
-
 The rules are as follows:
 
 1. If type is ``m.room.create``:
@@ -541,6 +530,30 @@ The rules are as follows:
     level.
 
 
+Rejection
++++++++++
+
+If an event is rejected it should neither be relayed to clients nor be included
+as a prev event in any new events generated by the server. Subsequent events
+from other servers that reference rejected events should be allowed if they
+still pass the auth rules. The state used in the checks should be calculated as
+normal, except not updating with the rejected event where it is a state event.
+
+If an event in an incoming transaction is rejected, this should not cause the
+transaction request to be responded to with an error response.
+
+.. NOTE::
+
+    This means that events may be included in the room DAG even though they
+    should be rejected.
+
+.. NOTE::
+
+    This is in contrast to redacted events which can still affect the
+    state of the room. For example, a redacted ``join`` event will still
+    result in the user being considered joined.
+
+
 Retrieving event authorization information
 ++++++++++++++++++++++++++++++++++++++++++