There is a list posted in the IDS/IPS forum here that was created by some of the forum members. It is a pretty decent one in terms of suppressing most of the popular false positives. Might be that the list you posted actually originated from here, I don't recall all the individual rules on the posted list.
The best way to suppress false positives in your setup is to put Snort in alert mode only (turn off Block Offenders) and let it run for at least a week, and maybe more, while analyzing your typical network traffic. Make it a point to review the alerts at least daily and more than once a day if possible. Remember that any generated alert is a block, so look at each alert and then use Google to find out what the alert really means if you are not sure. Use that info to construct your false positive list. Add rules to a Suppress List by clicking the plus (+) icon next to the rule's GID:SID value. If you want to disable the rule, click the red X. That is a more secure approach to creating a suppression/disabled list than copying somebody elses list off the Internet -- and that includes the list posted here ... ☺ . I'm just not a big advocate of copy-and-paste when it comes to IDS administration.
Resist the urge to install Snort and immediately turn on blocking. That is almost guaranteed to generate blocks from false positives and create a headache for the security admin. Let it run for quite some time in IDS mode (intrustion detection) only without blocking so that you have an opportunity to see what alerts happen with your network traffic. From that list you can determine what you will consider OK to let pass and what you may want to block in the future. With that said, I will say that most admins turn off several of the more troublesome HTTP_INSPECT rules. You can find those in the alerts by both their GID (Generator ID) code and the fact the message will ususally start with the string (H_xxxxx) where the xxxxx is the particular HTTP_INSPECT section. The HTTP_INSPECT preprocessor rules will have either GID 119 or GID 120, depending on whether the rules are designed for the server (120) end or client (119) end of the conversation. But the HTTP_INSPECT preprocessor rules are not all bad. Here is something I found while doing some research recently: https://www.trustwave.com/en-us/resources/blogs/spiderlabs-blog/detecting-brazilian-banking-trojans-with-snort-http_inspect/.