That kind of depends entirely on who/what you are unsubscribing from, and how intelligently they encode e-mail addresses through URL's, surely?
Maybe the problem you're running into is that the + character is special in URL's and must be escaped, otherwise it is treated as the representation of a space character. E.g. the URL parameter in <http://foo.example.com?unsubscribe&bob+whatever@domain> looks, after URL decoding by the server, like "bob whatever@domain". The software which inserted the e-mail into the URL didn't treat the plus properly, but the software which is decoding the URL is treating it like it is supposed to.
If that's the issue, the workaround could be as simple as manually fixing the URL in your browser, replacing the unescaped + character with its percent-encoding equivalent, %2B, as in <http://foo.example.com?unsubscribe&bob%2Bwhatever@domain>. The URL parameter bob%2Bwhatever@domain should now decode into bob+whatever@domain.
Try it next time.
It's easy to see how this could happen because the insertion of e-mail addresses into unsubscribe links in e-mail bodies is done by ad-hoc software probably cobbed together in house, whereas whereas URL parsing is done by generic URL handling code in a web server.
(But anyway, the whole point of this exercise is that we don't trust the unsubscribing. If unsubscribing could be trusted to be honored, we wouldn't need this extraneous e-mail address that we can recognize and junk.)