I am using the 2.1 SDK, which might make a difference. I also have a fairly complex email. But I have sorted it now, by upgrading to proguard 4.6 and adding the following lines to my proguard,cfg:
-dontwarn java.awt.**
-dontwarn java.beans.Beans
-dontwarn javax.security.**
-keep class javamail.** {*;}
-keep class javax.mail.** {*;}
-keep class javax.activation.** {*;}
-keep class com.sun.mail.dsn.** {*;}
-keep class com.sun.mail.handlers.** {*;}
-keep class com.sun.mail.smtp.** {*;}
-keep class com.sun.mail.util.** {*;}
-keep class mailcap.** {*;}
-keep class mimetypes.** {*;}
-keep class myjava.awt.datatransfer.** {*;}
-keep class org.apache.harmony.awt.** {*;}
-keep class org.apache.harmony.misc.** {*;}
The last group of lines is non-trivial. I obtained it by running tar tf commands against each of the jars in the javamail package.
Update for SDK 17
Android SDK 17 introduces some changes in the way that jars are loaded. If you have a project that uses external jars, upgrading to SDK 17 or beyond will probably break it. To fix this, select Project > Properties > Java Build Path > Order and Export from the menu, and check the boxes to left of the three jars used by javamail. This ensures that the jars get exported to the target build. Without this fix, the project will still build, but javamail will no longer work and proguard will also fail. This is not a proguard issue at all. It is an Android SDK issue. No changes to proguard.cfg are required.
Another consequence of upgrading the SDK is that it is no longer necessary to upgrade proguard manually.