Or they could apply URL canonicalization to tweets delivered any other way: follow all the 302s until they get the actual page, then replace with those URLs instead. (Actually, the best approach would be to canonicalize the URL on its way in, and then shorten with a single, known URL shortener on the way out, if sending via SMS. This would stop the "shortener wars" in its tracks, which is probably a good thing, because each shortener that dies leaves dangling links in its wake.)
What happens when something in the middle redirects infinitely, is slow, or is down? Does the tweet have to wait until canonicalization to show up? How long are people willing to wait? Is it acceptable to not be able to link to a site unless it's up?
As OpenID implementors have noticed, these issues cannot simply be ignored. Making an untrusted HTTP request is tricky business.
The nice thing about tweeting (and most tweet clients) is that you expect people to be linking to a site they just visited, not a random URL they typed from memory. (As long as the client says "checking links..." with a little spinner beside each URL getting replaced with a check or an X, I don't think users will mind waiting.) Also, "when something in the middle redirects infinitely", sharing that link would be malicious on the part of the poster, so it's okay to make them wait for some sort of time-out.
However, if you want to eat your cake and have it too, you can just change "canonicalize then shorten for SMS" to "always shorten, first pointing the shortened URL at the original URL, then asynchronously updating the shortened URL's target to the canonicalized URL, once the canonicalizing daemon has processed it."
Why would the users need to have a URL over SMS though? Couldn't it just say 'link?' Then the user could view the tweet later through another interface to get the actual URL.
