Fix broken IMAP attachments in Mail.app

I have recently started getting broken images in Mail.app. Often, when someone sent me relatively big pictures (over 1 MB in size), the image ended up being corrupted, with a smaller file size that one would expect. This results in a picture that’s visible up to a certain point, and then rest is usually filled with solid grey by the viewer.

While this could happen because the attached image is indeed broken — that is, if the sender is attaching an image that’s already corrupted on his/her machine —, it’s unlikely that the file gets mangled during the transit. To begin with, the base64 encoding adds lots of CRC (1/3 of the file size, and this alone explains why it’s a very bad idea to send big files through e-mail). In addition to that, no MTA will accept a malformed message: MIME parts must be completed with an extra boundary marker, and the infamous dot on its own line has to be there to commit the DATA part. Using a webmail system makes it even more difficult to corrupt a file in transit, because there is the extra uploading step that ensures that the attachment reaches the server before the message is constructed and finally sent.

If none of this makes sense and you want to know more, please refer to RFC 2821, but the point is that it’s virtually impossible for several people to send corrupted images. It’s way more likely that the problem lies within the recipient’s client.

With OS X’s Mail.app, these problems happen when there is some communication failure during the download of the message. Essentially, if the download gets interrupted for any reason, Mail.app may be unable to notice and will be perfectly happy with the broken file. There are two ways to fix this:

  • The hard way: go to ~/Library/Mail, and for each INBOX you may have, delete anything inside the Attachment folder
  • The easy way: select your Inbox folder within Mail.app and simply run Mailbox → Rebuild

That should take care of the problem. Note that the Rebuild procedure will redownload every message from the server again with all the attachments, essentially resynchronizeing the local cache with whatever is on the server, fixing any discrepancies. It may take some time, but you can keep an eye on the progress by opening the Activity window (Window → Activity, or ⌘0.)

Twitter’s RSS feeds are broken, and will stay broken

What happens when Twitter switches from basic authentication to OAuth? Clients that relied on the former will stop working, until an update comes to add support for the latter. This has been called the OAuthocalipse and aside from minor glitches with some programs, it happened without much of a problem, much like the infamous millennium bug (ah, those were the good times: free Kevin!)

One of the lesser used functions of Twitter has been brutally smashed by the switch to the safer authentication method, however, and in a way it’s quite ridiculous. I’m talking about RSS feeds that are — or should I say were — generated from the timelines and so on. It was probably not very used, given the plethora of dedicated Twitter client, but as a very basic user who is mostly in read mode, I really appreciated it. Of course, to get a feed of your own timeline you had to log in, and how do you do that? With basic HTTP authentication, of course. Not anymore.

Now, I’m sure that some RSS aggregators will implement OAuth. Whether the one I use will do that or not is still unknown. In any case, all of this is ridiculous for two reasons:

  1. RSS is strictly a read-only system, so adding an extra layer of complexity (in that it has to be implemented from scratch whereas basic authentication is handled by virtually all HTTP libraries and frameworks) takes time and ultimately money. The result is that many clients will be able to happily access all sorts of password-protected feeds except Twitter’s.
  2. Twitter still shows an RSS badge in most pages’ sidebar, and carries the appropriate meta tags in the <head> section to advertise the feeds to the browser. As if that were not enough, one’s own friends’ timeline (ie. the “main page” you see when you log in) has three alternate feeds: your timeline, your mentions and your favorites. Needless to say, none of them work. So why keep them up?

I’m not the only one with this problem. Commenter #8 on this post, Dan Lyke, says:

I’m now considering whether I want to bother keeping my Twitter presence at all. Sure, I could write a Twitter reader of some sort that changed things into RSS, or run an app just for Twitter, but in a few hours Twitter has gone from being a part of my usual work flow to a freakin’ hassle.

I feel exactly the same way, and to me Twitter wasn’t even “part of my usual workflow.” I seldom write and I just use it to get updates from very few users / companies. I guess I’ll check it much less now that I have to open up the page, as I have no intention of using yet another program just for that. When I have some time I’ll probably end up writing a thin wrapper around OAuth to get an RSS feed out of my timeline, but right now I’m not thrilled about this.