In my experience the "stupid shit" and "crap you don't want" is often useful feedback. At the very least, it tells you which parts of your app are most confusing.
For example, if you get lots of complaints about something you consider obvious, maybe you should reconsider what's obvious. Often minor changes like improved docs or more googleable error messages can improve the experience for many users. And you'll see if changes are effective as soon as a specific sort of "crap" stops showing up in your bug reporting system.
Except when tons of emails come in that can't even coherently describe the part of the program that doesn't work or the approximate process they are attempting.
You can always ignore these incoherent emails. But if you put up some kind of filter before people can contact you, it won't be your decision which feedback you ignore.
And, if you really try, you can often extract valuable feedback even from what seems to be incoherent babble at first.
You can, but sorting through them has costs measured in time. Filtering through dozens of drug report and smug reports for a useful bug report is not instantaneous.
When your entire project is just you in your spare time or maybe a handful of volunteers, that filter is the difference between support being helpful and support being a useless hellhole. And believe me, when the vast majority of support requests are useless crap, you lose motivation to care about those people with truly impressive speed.
For example, if you get lots of complaints about something you consider obvious, maybe you should reconsider what's obvious. Often minor changes like improved docs or more googleable error messages can improve the experience for many users. And you'll see if changes are effective as soon as a specific sort of "crap" stops showing up in your bug reporting system.