There has been a long-standing issue with users sending modmail when they're trying to make a new text post to the subreddit. From examining a number of examples of this happening, it appears that they tend to do this by going to a message page (inbox/unread) by clicking the envelope icon, then they click the "compose" tab, and type the name of the subreddit into the "to" box. This commit updates several labels to make it more clear that it's a private message that's going to be sent, not "posting a message publicly".
72a2cc6 was only counting messages sent to the subreddit.
The space compressor has a habit of changing the semantics of text, and we generally work around it by `text.replace(" ", " ")`. We know that the format string passed to `_wsf()` won't contain HTML, so we don't have to worry about mucking with spaces between attributes. Just automatically work around the space compressor by default.
Thanks to a report by /u/wicro
Mods are able to mute a user from modmailing in for 24 hours. They can click 'mute user' on the modmail of the sender they want to mute or go to /about/muted to manage all of the muted users. If the user has interacted with the subreddit, they will be messaged about the muting. If a subreddit or user try to message each other when the user is muted, they will get an error message and it won't go through.
That way when you're browsing on www.reddit.com, you'll always have an up-to-date policy for .reddit.com as well.
There've been a few instances in the past where we poisoned downstream caches with loggedin responses for several hours before realizing it was happening. Each time we only realized it once a user reported that they were being logged in as someone else. This PR attempts to make it easier to detect upticks in cache poisoning by adding a cache poisoning canary cookie. The canary cookie is a random, non-identifying, persistent cookie that is included in every request and sent back with every loggedin HTML response. If the canary in the response is different from the one we would have sent, we know that cache poisoning occurred. If the client detects it has been served an improperly cached page, it tries to gather extra data about the page (such as some of the headers sent with response for the current page.) With those, we can often figure out _how_ the cache was poisoned (did CF cache it, did an intermediary proxy mess with the `Cache-Control` headers?) We can also sometimes find out what was served with the poisoned response, and if the victim is now likely able to perform actions as the poisoner.) We also keep track of what cache policy was used, so we can experiment with incremental rollout of new cache policies and see how they affect the incidence rate of poisoned caches. We keep track of the overall cache poisoning report rate in tallier, and send a more detailed report to event-collector so we can figure out what's causing all the poisonings and who was affected after the fact. : https://en.wikipedia.org/wiki/Buffer_overflow_protection#Canaries
This gives us a way to test if a cert will likely cause problems when used in production, and see who it will cause issues for.
This has since (July 2015) been fixed upstream, but it hasn't been packaged for many (any?) distros yet.
This reverts commit b48efd8f72f32b6698be2a96c29a5ecc18f1b5a4.
Emails are only getting associated with a specific account if they're queued up due to an action by a logged-in user. This is impossible with password-reset requests and the subsequent email for a successful change, but those should definitely be associated with the account that is being reset.
This reverts commit e992745.