Using Gmail as SMTP server for a non-gmail account

[mgagnonlv]

Hello,

To make a long story short, I have a "Gmail at work" address that forwards all email I receive on a different non-Gmail account (me at myaccount.com). I want to configure the account so that mail I send from that account goes through Google's SMTP server.

In Thunderbird, I setup my incoming mail credentials (me at myaccount.com) using IMAP, then select the outgoing server as Gmail's server (smtp.gmail.com). Thunderbird will correctly use an SSL connection for IMAP access and uses the OAuth protocol to sign into Google's SMTP server.

Is it possible to achieve the same in Aqua-Mail?
Right now, I have done so by "allowing access to less secure applications", but I'm afraid Google will shut down that possibility later on.

Michel

P.S. Great program. I have the Pro version.

[Kostya Vasilyev]

No, sorry, OAUTH is only supported at "whole account" level, not identity's sending server level.

It should be possible to add the "address from which you collect mail and from which you wish to send mail" as an additional "address to send from" in Gmail web mail settings, under your Gmail account -- and then it should be possible to send messages "from" that "additional address" through Gmail's SMTP, without setting an identity's sending server.

Haven't tried it with Gmail at Work / Google Apps, but this is how it works -- and works quite well -- with personal Gmail and accounts elsewhere.

The main thing is that by adding the "other address" in Gmail web settings, you're telling Gmail to NOT rewrite the "From: <other address>" header.

[nica]

It should be possible to add the "address from which you collect mail and from which you wish to send mail" as an additional "address to send from" in Gmail web mail settings, under your Gmail account -- and then it should be possible to send messages "from" that "additional address" through Gmail's SMTP, without setting an identity's sending server.

This is not possible anymore. There was a change in 2014 (for new external addresses):
http://googlesystem.blogspot.co.at/2014/08/external-addresses-no-longer-use-gmail.html

For sending from external address through Gmail you have to enter login name and password. The original SMTP server will be used, not Gmail's server.

If configured in this way (and added this identity to the Gmail account in AquaMail), there is no problem to send mails with an external address in AquaMail of course.

[Kostya Vasilyev]

I don't remember now -- maybe it was necessary to add my "other" mail account's SMTP server and password in Gmail settings, when adding this address as "another one to send from", but that wasn't my point --

-- my point was, from AquaMail's point of view, it still is possible to send messages "From: alias" through Gmail's SMTP server, logged in as under the "parent" account.

And this will use OAUTH if the account is configured as such (the original issue raised in this discussion).

What goes on behind the scenes -- whether GMail's SMTP does the sending itself, or re-routes through the "other" mail account's provider and its SMTP -- really makes no difference in terms of how you configure AquaMail for this, and the ability to use OAUTH.

PS - Read the linked post, seems it's mostly because of DKIM / SPF, makes sense. Thanks for the link, good to know.

[StR]

-- my point was, from AquaMail's point of view, it still is possible to send messages "From: alias" through Gmail's SMTP server, logged in as under the "parent" account.

...

What goes on behind the scenes -- whether GMail's SMTP does the sending itself, or re-routes through the "other" mail account's provider and its SMTP -- really makes no difference in terms of how you configure AquaMail for this, and the ability to use OAUTH.

PS - Read the linked post, seems it's mostly because of DKIM / SPF, makes sense. Thanks for the link, good to know.

Kostya, I am not sure if your PS means that you realized it, but just in case: your first statement quoted above is no longer correct for newly set aliases. While it might still work for the grandfathered aliases, for the new aliases, Gmail's SMTP will not do that. My understanding is that mail will get sent directly to the alias' "native" SMTP.

A brief aside:
While I agree with the motivation related DKIM/SPF, etc., I think a better solution would be to allow that sending via their SMTP in case one can control their DNS records, thus setting up DKIM/SPF, etc. accordingly. This would be important to those users who do not have their own SMTP servers for their "personal" domains.

[Kostya Vasilyev]

While it might still work for the grandfathered aliases, for the new aliases, Gmail's SMTP will not do that. My understanding is that mail will get sent directly to the alias' "native" SMTP.

My test alias is fairly recent, the linked article is from 2014.

What Gmail does "behind the scenes" doesn't matter to me -- what matters to me is smtp.gmail.com being able to accept messages with "From: alias", authenticated under a @gmail account, and not rewriting this header.

And this, I believe, it still does.

[nica]

It does. Works like a charm.

I have 6 external accounts in my gmail account. Easy to deal with it, better as to set up 7 accounts separately.

And composing/sending mails with each of these accounts works as it should in AquaMail (using identities within the gmail account).

[mgagnonlv]

Hello, 

Thanks for everybody's replies.

It is nice to know that it would have worked the other way around: i.e. use Gmail's contact info with either another identity, or simply a copy of its messages to the backup server.

Yet, I will likely continue to use my current configuration as long as Google still allows "less secure applications". It seems to me easier for 3 reasons:
– No need to reconfigure Thunderbird and all filters.
– Messages are stored out of Google, where I ultimately want them to be.
– If I have my personal Gmail account and the corporate Gmail one too, my telephone constantly asks me which account I want to use – for mail, text messages, photos, maps, agenda events, etc. It works, but it's less fun.