Signal's server doesn't know who sent the message, since that information was Sealed.
Signal's server does know where to deliver the message to, based on a 96-bit random value generated client-side by the recipient (the delivery token). But it cannot know which user has which delivery token. To understand that, you need to look at the zero-knowledge credentials section of the code.
They could randomly drop messages sent to a specific targeted user's delivery token and block messages sent to that targeted user, but they have no way of knowing which user they're targeting. (Also, the client could just enroll a new one if this ever happened and Signal was somehow court-ordered to block delivery to a specific delivery token.)
I.e. is a sender able to prove that it's impossible for signal servers to do this?
See https://signal.org/blog/sealed-sender/ and https://eprint.iacr.org/2019/1416 if you'd like descriptions for the protocols I'm trying to describe in HN comments.
> Without authenticating, hand the encrypted envelope to the service along with the recipient’s delivery token.
I'm probably going to need to read the white paper to actually understand this, because currently I'm confused as to how this doesn't result in knowing the destination. Surely I can reverse the delivery token if I'm in control of the servers?
but I was thinking network based disambiguation
edit; seems there's (maybe was?) a number of ways to disambiguate targets, users, and contact graphs https://www.ndss-symposium.org/ndss-paper/improving-signals-...