Defragmenting the kernel development process

Yes, that's the one.

I think spam is a solvable problem.
If you required the HEAD pushed to always have a signed tag, then you would have a basis for establishing reputation (and you would encourage tag signing, which is a *good* *thing*).

If the signing key doesn't have reputation, the pushed information is limited in some way and it not forwarded to any (public) email lists.
In that case, the author needs to copy some text that was returned by the server into an email message - which can be sent with any old MUA. IT would include a link to find the patch.
I'm not sure how reputation would be gained or revoke, but some combination of automatic flow analysis and crowd-sourcing (if 3 reputable keys vouch for a new key, it gets reputation?)

You wrote that "support in git-daemon is needed" but I think it provides everything you need. You can certainly enable anonymous push, and there are hooks that allow you to check any change to the repo before it happens, so you should be able to prototype something yourself.