iOS access recent emails - iphone

I know this is likely to be answered "sorry buddy", but is there a way i can access my recently sent emails from another iOS app? I really don't need the contents of the emails just the addresses. Basically if you haven't stored the contact information in your address book, I still want to be able to pull those addresses.
For example in the email app, when you compose a new email, as you start typing in an email address it will try to autofill with recently sent/received email addresses. I'm trying to mimic this behavior.
Point me in the right direction if there is already a stack overflow question about this.

No, there is not API that will allow this.
Apps can't acces other apps data since they are sandboxed.

Given the quick answers I received confirming my suspicion that this can't be done, I'm thinking I will just provide a way people can set up email accounts the way the built-in mail app does it. By that I mean I will allow people to select from the major web-based mail providers like gmail, yahoo mail, .. then also allow them to create a mail account with their mail server (address, username, password, port, etc.)
It's kind of overkill since I just want their recently used email addresses, and will scare off people who don't want to give access to their personal mail, but if its all i can do then so be it.

Related

Send email from Google Workspace Catch All email

I’m currently using Apple Hide My Email to create random email addresses for each website I create an account on. I really like the privacy and spam control I can get from this feature, but the Apple email client is terrible, and the process to create a new email is also terrible, specially when I’m not on my iPhone.
I would love to simulate this whole experience using a catch-all email config through Google Workspace. However, I don’t think I would be able to reply to incoming emails using the same email address that I used to create the account.
Is there a way to send emails from the email addresses I’m creating through a catch-all config on Google Workspace? If not, would it be possible to simulate the experience I have with Apple’s Hide my Email on Google Workspace?

How much of a bad idea is it to allow users to send arbitrary emails via our servers

My company is developing a cloud contact management service and on our iOS app we're having some problems launching a particular enterprise email client app when the user presses the "Email" button on one of their contacts.
One member of our team came up with an idea to get around the problems with this enterprise app:
We let the user specify their email address in the app's settings and create our own email composing screen. Tapping the email button on a contact would open the composing screen, they would write their message and then we would send it on their behalf from our servers (or via service like mailchimp).
Basically, this would mean we would have to create an endpoint on our api that would accept a POST request with 'from', 'to', 'subject', and 'body' fields which would send the appropriate email.
This seems like a very bad idea as it's essentially creating a free, anonymous email service that could easily be abused send spam.
A few extra notes about our setup:
We don't verify an accounts email when they sign up
Even if we did verify the account's email, the user would need to be able to specify any email, as they may have signed up with personal email, but want to email someone from their work email.
Our API doesn't currently have any kind of rate limiting
Instead of having a from field in the request, we could instead send the id of the contact they want to email. This doesn't really change anything because if someone wants to abuse the send email endpoint they can also abuse the create contact endpoint.
So exactly how much of a bad idea is this, and how can I convince my team not to do this?
A few thoughts against doing it:
This is the perfect spamming service, which could damage the reputation of your company (reputational risk).
Your email servers would very quickly make it into blacklists (RBLs), making your outgoing emails land in spam folders in very many recipients' mailboxes.
Even if your servers are not yet in RBLs, if you send a forged email like that and proper email security is set up at the recipient end, your emails will still have a good chance to get classified as spam. Have a look at things like SPF and DKIM.
This could even have legal implications. Imagine the scenario when one of your users uses this service for something like blackmail. Would you be able to prove it was not you? Probably yes with the right controls, but would you want the hassle?
Still on the legal side, many countries (the EU, mainly) have data protection regulations which strictly control how personal data like email addresses can be used, especially for commercial advertisement. You probably want to adhere to that, but that would be hard with such a service (note that I'm not a lawyer, in such a case it's probably the abuser of your service that would offend these regulations and not you, I don't know, but it's something to consider).
If anyone can just send emails, it will be fairly easy to perform a denial of service attack against your services.
A few controls you could implement to mitigate some risks:
When adding a sender (from) address, you should validate that by for example sending a (cryptographically random) token and checking if the user can send it back (eg. by clicking a link in the email). If he can, that proves to some extent that he controls the email address and is probably a valid sender.
Limit the possible recipient addresses if you can. The best would be if recipients had to opt in to receive emails. If this is not possible, at least let recipients opt out from further emails. For this, you would have to add something like a footer to emails with "never again" links, and implement a facility to maintain recipients to which you must not send anymore.
Implement rate limiting. Depending on your exact scenario and use case, only allow to send the least number of emails acceptable for your application.
Implement proper logging so that you have an audit log of who exactly sent what email to whom. For this, log metadata like IP addresses as well. For this, you will likely have to authenticate your users.
On an operational level, have monitoring in place, and be prepared to ban offending users, based on a clear ToS shared with your users.

GameCenter Players' data

Can I send a message via mail to top players in the leaderboard?
Is there a way to get the list of their emails?
I'm pretty sure Apple will never give a user (or developer) another user's personal information, such as their email address. That would lead to all kinds of abuses and ill will.
You can ask for information in your app and some people will voluntarily give it, although a lot will not. You would have to provide your own server to collect the information; there's no game center function that passes information from the user back to the developer other than game statistics.
If email is the only thing you want I think Apple will approve an app that gives the user some reason to email you then you can use the From: or Reply To: address to communicate back to them. But that would still be voluntary on the part of the user.
If you have an email address, you can use MFMailComposeViewController for sending an email. Hope I helped.

Send mail without MFMailComposeViewController

I want to send mail from an iPhone app without showing an MFMailComposeViewController. I also want this mail to be sent from the user's default Mail account. Is it possible to do this?
This is not supported by the iPhone SDK, probably because Apple doesn't want you to do it.
Why not? My guess: Because it's easy to abuse. If we knew user's email address, we could spam them, we could fake emails from them, etc. Imagine finding out an iPhone app sent an email as you without your knowledge -- not cool, even if the app had good intentions.
So, anything you do to get around that, is likely to get you rejected from the app store.
Having said all that, you could basically write your own smtp interaction code to chat with the user's outgoing mail server. For example, if the user has a gmail account, you could ask them for their email and password, you'd have to know how to talk to the gmail servers, and send email through them.
Going that route means asking the user for their username, password, and either asking for or figuring out their mail server information. Another choice is to send directly from the phone (your own smpt server, not just a client), which is a bit more coding. And if you write your own server, the mail you send is more likely to be blocked since your originating IP might not match the domain on the sender's email.
There also exist some libraries that might help out. Previous related question:
Open Source Cocoa/Cocoa-Touch POP3/SMTP library?
There are legitimate reasons for wanting to send an email. (Such as communicating with a server using SMTP instead of HTTP)
This blog post should get you going: http://vafer.org/blog/20080604120118
It is possible to use MFMailComposeViewController without user interaction. See my answer on the iPhone send email not using MessageUI question.

Setting up a no-reply email address with Google Apps [closed]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 8 years ago.
Improve this question
I have my domain's email set up with Google Apps, and I am interested in sending automated emails (when users register, for example) with the From and/or Reply-To field being "no-reply#example.com". I have a few questions pertaining to how this is done:
Should I actually set up a user in Google Apps named "no-reply"?
If not setting up a "no-reply" user, should I log in with a real address (e.g.: "support#example.com") and send the email as being from "no-reply#example.com" instead? Or should I simply use the Reply-To email header?
If it's necessary to use the Reply-To header, is there a way to block the true From address (i.e.: the username I used to log into Google's SMTP server)?
Yes, you should setup a separate noreply address on your email server.
There are excellent reasons why you should set up a no-reply email address.
Why is it important to have a no-reply on bulk emails?
Many of the recipients of the email will try to hit 'reply' and they will have a multitude of reasons for doing so. Often, it is not sensible to have all of these going to a single representative at your company. Furthermore, many emails from bulk lists will be bounced back. You don't want to have to sift through these in order to find legitimate questions from your mail outs.
The best way to respond to questions rather than replying to bulk emails, is to have the recipients direct their questions to appropriate response emails either through their usual contact or via your company website.
What if recipients DO hit the reply button?
The email originator for the bulks should not just silently swallow the replies. Many companies do this and as a result, legitimate replies are ignored without any indication to your client or potential client and they, feeling neglected, go elsewhere for business.
The originating email account should be set up with an auto-responder explaining that the email was not processed and suggest alternative ways of contacting your company.
In gmail this can be done by setting up a Vacation responder with no last day. You can find the Vacation responder feature under the General tab of the account settings.
Avoid having extra accounts by setting up no-reply as a group that restricts users from outside your domain sending to it.
Unless you can think of a really good reason for it, I would suggest that you send your emails from support# rather than no-reply#.
The whole reason for a support# email address is to receive comments and feedback from your userbase, and if you're sending them emails why bother making it hard for them? If they can just reply to the email you'll receive way more feedback that way.
I suggest you set up a "Nickname" alias ( Manage Domain > Users > edit user > Add Nickname ). Then create a filter that sends any reply to that nickname straight to trash or spam.
Just set up a "no-reply" account. It won't hurt anything, people will still try to send stuff to it, and it will serve your purpose.
As for the latter two questions, it depends.
If you're sending these e-mails as a part of an automated script (i.e. forum registration) just use the "no-reply" accounts credentials. Log in periodically to make sure you aren't getting legit delivery errors (as opposed to the jokers that use fake e-mail addresses) or other odd behaviour.
If you're not sending these e-mails as a part of an automated script, it depends. If you also manage a support address (support#example.com, staff#example.com, etc.) you may want to send on behalf of, and use the reply-to. But this part is a little more subjective, and really depends on your setup.
I don't know if this will help or not, but IIRC, with gmail you can do something like
name+something_else_here#domain.com
Then, set up a filter so that emails with that "something_else_here" part go past the inbox to a label.
Does that help?
I think creating a user named no-reply is a bad approach. An alias or a restricted group is a much neater and functional solution IMHO. Also, google apps cost is based on user number.
A cool way to handle this would be using the vacation setting in GMail to send an automated response back on the no-reply email address. The vacation reminder would then remind users that this is an unmonitored email address.
I think the right thing to do is setup a filter that sorts your mailer-daemon messages into a special folder (Or trash if you so desire.) Or, like other comment have suggested, use a separate mail address.
noreply is good to indicate to people that this isn't an address you check, but it's not really the solution to dealing with bounce mail. In fact it's more likely your mail will end up in spam filters because your attempt at sender obfuscation will just look like spam to the receiving host.
You should create a noreply user. But use it as a spam mail (when registering unknown sites) and a mail for testing.