1

I need to send emails from an app. Until now I've used the JavaMail Api which works well but has some problems:

  • I need to hardcode the password to the gmail account from which the mails should be sent, which obviously isn't great
  • Google recently detected some "suspicious sign ins" (I don't know if this was actually some people who tried to access the account or just the normal sign ins from the app), but google forced me to change the password, which obviously made the app useless because it couldn't send emails anymore.

I don't want to always release an update just because I had to change the password.

So if you have any ideas on how to either:

  • make the hardcoded password pretty secure and preventing google from forcing me to change the password

  • or sending the emails some other way that doesn't need a hardcoded password (like through a http request but that doesn't really work because the server thinks I'm spamming around and blocks the webspace...)

Please help!

DominicM
  • 2,186
  • 5
  • 24
  • 42
  • Why don't you send an Intent to the standard Android Mail app? – Egor Mar 23 '13 at 17:54
  • 3
    "I need to send emails from an app" -- why? If the user is actually the one sending the emails, then use `ACTION_SEND` and allow the user to complete the process using their favorite email client. If you are sending emails behind the user's back from the user's device, why do you think that this is something the user would want? – CommonsWare Mar 23 '13 at 17:55
  • http://stackoverflow.com/questions/2020088/sending-email-in-android-using-javamail-api-without-using-the-default-built-in-a. Agree with Commonsware comment – Raghunandan Mar 23 '13 at 19:24
  • 1
    There are a thousand of reasons why the user would want to send an email through an app without him having to interact with the device, like e.g. for an anti theft app where an email should be sent if someone moves the device. I mean I don't want to send an email from the users account, I want it to be sent from my account through the app. – DominicM Mar 23 '13 at 21:53
  • That's correct. You just need to make a distinction between emails that need to be sent on the users behalf (cfr: something the user wants to share with people using twitter / facebook / email / text message), and something that you application needs to send in the background, part of your application business logic. If your app sends an informative message to the user (or other users of the app) than I feel you're better of letting your application backend deal with that and keep it outside of your app. – ddewaele Mar 24 '13 at 13:54

3 Answers3

2

If you want the app to generate emails and send them to the user the best way is to send the email from a backend system. Publish a REST API that your mobile application can interact with and have that backend deal with sending the email. It will be more secure and you'll have proper decoupling. It's the only good way to deal with it.

Encoded passwords in an app can always be decrypted, as the encryption key will also be stored somewhere in the app. Plus as you already stated, the hassle of having that code sitting in your app, and the difficulty of updating that code can be a nightmare (not all users update their apps frequently).

If you want the app to send emails on behalf of the user (making it as if the user is sending them), then use an Intent as CommonsWare stated in the comments. It makes it visible to the user that an email is sent.

ddewaele
  • 22,363
  • 10
  • 69
  • 82
0

Not sure how often it has to send emails, but you could encrypt the password with a 4-digit pin, then upon startup ask for the pin, decrypt the password and keep it in memory. You'll need to re-decrypt it if you get swapped out, but it will keep the user's password more secure.

Dave
  • 300
  • 1
  • 7
0

I concur with ddewaele: a proper API is necessary. Note that there are online services that offer easy APIs for you. For some examples, see Backend server provider for mobile apps. Some are free for a small number of users.

Community
  • 1
  • 1
Bram Geron
  • 273
  • 1
  • 12