RC2 is a currently "unbroken" block cipher; the best known attack is a "related-key attack", i.e. something which does not really apply in practice (related-key attacks are about specific properties when the victim uses two distinct keys, that the attacker does not know, but with a difference between them that the attacker knows).
RC2 still has some suboptimal properties:
It uses 64-bit blocks. This makes it unsuitable to processing large data sets, the cut-off being around 2n/2 blocks when blocks consist in n bits. For a 64-bit block cipher, this amounts to about 30 gigabytes with a single key, which is large but not unattainable in some contexts. Encrypting more data than that implies a risk of revealing part of the plaintext. Note that 3DES suffers from exactly the same limitation. For encrypted emails, you should be OK with that.
Its performance sucks. About as much as that of 3DES; on my (underpowered) laptop, OpenSSL's implementation achieves about 10 MB/s with 3DES, 12 MB/s with RC2. There again, for emails, this should not be an issue.
RC2, in its description, uses a lot of data-dependent lookup tables. In that sense, it would be very difficult to make an implementation that is "constant-time" (i.e. does not leak information to attackers that can run their own code on the same hardware, through cache-induced timing differences); at least, it would be very difficult to make one without a massive slowdown (like a 100x slowdown factor). Note that classic 3DES implementations are not constant-time either, but that can be done with only a "moderate" (relatively) slowdown (about 3.5x with my own code).
Since email sending is asynchronous, and moreover since email encryption and decryption tends to happen on the user's desktop computer, not on a shared server, this kind of side-channel leakage should not be a big concern anyway. Unless you decide to upload private keys on a server, in which case the concerns may come back -- make sure, at least, that the server is not hosted in a cloud that shares the very same hardware with outsiders.
RC2 has a configurable key length, between 1 and 128 bytes (i.e. 8 to 1024 bits, and multiple of 8). Thus, while RC2 itself can be a tolerably fine algorithm, it can still be used with a key which is way too short for ensuring a decent level of security. RC2 also includes an additional parameter (called "effective key length") that can be used to limit the brute-force resistance. Historically, RC2 has been much used in setups meant to comply with the pre-2000 US crypto export rules, with a typical strength equivalent to 40 bits (i.e. not strong at all).
The fourth point is, in my opinion, your biggest risk when using RC2. You do not really know how large the actual encryption key is; if the software you use does not document that information, then you do not really know how strong the encryption will be. Moreover, software that uses RC2 might be a bit lacking in maintenance...
To sum up, there is nothing really wrong in RC2 itself for encrypting emails, but the implementation still has ample room for doing stupid things that annihilate security.