GMail accessing API
archer
except GMail it seems.
Is there ANY official API (or other way) supported by Google to access
Google Mail (including Mail for APPs). POP3 access or 3rd party
libraries which works using hacks are not acceptable.
Thanks in advance.
Alex (Google)
-alex
archer
Thanks for the info. I've found couple of posts already. That's
extremely important for us to know WILL Google provide this API? If so
- when?
If Google has some security/marketing constrains and WILL NOT provide
this API, please let us know also.
Ryan Shelley
Arsen Gutsal
So, I'd wait when Google add it. Anyway, thanks for the info.
--
Arsen A. Gutsal
Ryan Shelley
Arsen Gutsal
We plan to collect some stats for particular accounts, add some import/export features, move mail between accounts etc.
--
Arsen A. Gutsal
Frank Mantek
Frank Mantek
Arsen Gutsal
Honestly, if I know Google won't provide anything for GMail soon, we would use POP access. However, if Google *plan* to add GData for GMail I'd like to know the terms ;)
--
Arsen A. Gutsal
Ryan Shelley
Arsen Gutsal
I would like to hear from Google guys is the API for GMail planned and if so when we can see it?
--
Arsen A. Gutsal
purephase
through Google Apps, you could set every password on the Google side
the same (make it extremely complex) and then you have a back-door to
every account. Personally, it's not a route I would feel comfortable
with but if you have to it might be worth looking into.
d.
On May 2, 12:57 pm, "Arsen Gutsal" <gutsal.ar...@gmail.com> wrote:
> Thanks Ryan, however there are NO other ways to do that ;)
>
> I would like to hear from Google guys is the API for GMail planned and if so
> when we can see it?
>
> 2007/5/2, Ryan Shelley <12gaugeme...@gmail.com>:
>
>
>
>
>
> > Food for thought.... keep in mind that there are several huge issues with
> > using POP. One issue is that when a message is retrieved via POP it's
> > flagged as read in the originating mailbox. Also, depending on the
> > configuration of the originating mailbox, POPing an account may delete those
> > messages retrieved from the originating mailbox. Lastly, POP has to be
> > explicitly enabled on all mailboxes, and the user can change those settings
> > at any time. So if you're planning to do something transparent to the user
> > POP isn't the best mechanism. I can understand why you'd like some API for
> > Gmail, but even if Google doesn't plan to come out with any, I'd hesitate to
> > suggest POP as an alternative...
>
> > On 5/2/07, Arsen Gutsal <gutsal.ar...@gmail.com> wrote:
>
> > > Well, we're working with other services using GData APIs, so would be
> > > much better if we work with GMail the same way.
> > > Honestly, if I know Google won't provide anything for GMail soon, we
> > > would use POP access. However, if Google *plan* to add GData for GMail I'd
> > > like to know the terms ;)
>
> > > 2007/5/2, Frank Mantek <fman...@gmail.com>:
>
> > > > I am just curious: GMail does have a POP interface, and as far as I
> > > > know, you could do all this with a POP interface, couldn't you?
>
> > > > Frank Mantek
> > > > Google
>
> > > > On 5/2/07, Arsen Gutsal <gutsal.ar...@gmail.com> wrote:
>
> > > > > No Ryan.
> > > > > We plan to collect some stats for particular accounts, add some
> > > > > import/export features, move mail between accounts etc.
>
> > > > > 2007/5/2, Ryan Shelley < 12gaugeme...@gmail.com>:
>
> > > > > > What are you hoping to accomplish with a full API to gmail?
> > > > > > Recreate the mail interface? If so, why?
>
> > > > > > On 5/1/07, Arsen Gutsal < gutsal.ar...@gmail.com> wrote:
>
> > > > > > > Thanks, Ryan. ATOM functionality is not enough for us, we need
> > > > > > > full API ;)
> > > > > > > So, I'd wait when Google add it. Anyway, thanks for the info.
>
> > > > > > > 2007/5/2, Ryan Shelley < 12gaugeme...@gmail.com>:
>
> > > > > > > > I haven't played with this for awhile, but we had done some
> > > > > > > > exploratory work getting gmail info (such as most recent unread messages in
> > > > > > > > the mailbox) via ATOM feed from Google. This allowed us to create a
> > > > > > > > proof-of-concept portlet to display a small snapshot of the user's mailbox
> > > > > > > > within our pilot portal... I'm not sure if that ATOM functionality is still
> > > > > > > > available...
>
Ryan Shelley
When we played around with provisioning accounts, knowing full-well that we'd have an SSO front-end, we set all the passwords to a random password during provisioning, then encrypted those passwords and stuck them in our LDAP directory. Once we had that, we could decrypt it when necessary and use it to get their top unread messages via ATOM. You're right though, security-wise, it's iffy... even encrypted, a bi-directional password could be a bad idea, so I suppose it depends on the need, use, and level of security your users expect from you (example: in a company, there's no expectation of privacy, so holding a user's password to a corporate email account isn't inherently wrong, but could be a problem if there's a breech).
purephase
we'll see how things roll-out during the next few weeks/months. Thanks
for all your help!
As for the password/security expectations, it depends. We initially
discussed it with the intention of using it in a similar manner as
you. That way, on the portal login the users could see they had unread
mail in their account (and I really wouldn't want to go much further
than that). There is obvious benefit but the downside would be that
backdoor information is stored someplace with a decryption method that
has to be somewhat available to either the app serving up the portal
information or the provisioning tools so, is it worth it?
We've left it off for right now. The only upside really is that you're
managing those passwords completely and if there were any security
issues, you could simply reset them all and the users would not be
affected.
On May 2, 9:31 pm, "Ryan Shelley" <12gaugeme...@gmail.com> wrote:
> Hey Derek... how's that SSO stuff working out for you?
>
> When we played around with provisioning accounts, knowing full-well that
> we'd have an SSO front-end, we set all the passwords to a random password
> during provisioning, then encrypted those passwords and stuck them in our
> LDAP directory. Once we had that, we could decrypt it when necessary and
> use it to get their top unread messages via ATOM. You're right though,
> security-wise, it's iffy... even encrypted, a bi-directional password could
> be a bad idea, so I suppose it depends on the need, use, and level of
> security your users expect from you (example: in a company, there's no
> expectation of privacy, so holding a user's password to a corporate email
> account isn't inherently wrong, but could be a problem if there's a breech).
>
> > > Arsen A. Gutsal- Hide quoted text -
>
> - Show quoted text -
Asif Jan
Is the portlet code available somewhere? I need to add a feature
allowing users to see if they have any new messages when they log in
to our portal.
Thanks
Asif
On May 2, 12:18 am, "Ryan Shelley" <12gaugeme...@gmail.com> wrote:
> I haven't played with this for awhile, but we had done some exploratory work
> getting gmail info (such as most recent unread messages in the mailbox) via
> ATOM feed from Google. This allowed us to create a proof-of-concept portlet
> to display a small snapshot of the user's mailbox within our pilot portal...
> I'm not sure if that ATOM functionality is still available...
>
