Re: gmail+SMTP(only) (oauth2)

[Tim Cross <theophilusx@gmail.com>]

Uwe Brauer <oub@mat.ucm.es> writes:

> [[S/MIME Signed Part:Undecided]]
>>>> "TC" == Tim Cross <theophilusx@gmail.com> writes:
>
>> Uwe Brauer <oub@mat.ucm.es> writes:
>
>>> Hi
>>> 
>>> Today I got the unofficial approval to forward my email to an account of
>>> my choice, if I can't access my mail with TLS (SSL or the gmail app
>>> password anymore)
>
>> So are you saying your institution won't allow you to use app passwords?
>> If they do, I would highly recommend going that route as the most
>> reliable and easily maintained approach. Note that even with the app
>> password solution, you still are using TLS both with imap and smtp. 
>
>
> No, I did not say that, but I have seen rumors that google will drop also
> the app password approach, in which case this route is not any longer
> possible.
>
> However, I don't remember where I have seen it.
>
> Do you have information regarding this subject?
>

My recollection is that when Google originally announced the intended
changes (back in 2017 or 2018), they indicated they would be removing
app passwords. However, when I go through their current announcements
and documentation on their support site, I cannot find any mention of
removing them. Furthermore, much of their documentation appears to have
been updated to state that app passwords are the preferred solution for
clients who cannot do oauth2/2FA. My guess is that there was sufficient
push-back after the original announcement that they reviewed their
proposal and are going to leave app passwords in place for the time
being. Even if they do decide to remove them, I would expect they will
give a fairly lengthy notice period (It has been 4+ years since they
flagged the removal of being able to use your normal google password). 

I would just use app passwords and wait to see what happens. A lot can
change in a couple of years. 

>>> 
>>> However I have been warned that the message should have a from field
>>> with a domain of my university. (@mat.ucm.es for example).
>>> 
>>> Now I could either use
>>> 
>>> 1. The smtpmail (or sendmail) program of my linux machine (not sure
>>> about MacOS
>
>> No, at least not on its own. You may well use smtpmail to communicate
>> with an SMTP server, but you will need to identify a new smtp server you
>> can use which will allow you to use a from header which is not the
>> 'standard' for that server. You cannot just use an SMTP server running
>> on your local Linux desktop - at least not if you want to ensure
>> reliable mail service and avoid having your messages dropped into
>> blackholes and anti-spam quarantine systems. Some services might allow
>> you to configure your local desktop sendmail (or postfix or whatever) as
>> a satelite/smarhost which relays messages to the main SMTP service, but
>> your really just adding complexity with little benefit and will likely
>> run into all sorts of ISP issues (especially if your system is a laptop
>> which connects via different networks).  
>
> I see, I might be able that my machine will be registered in our DNS
> databank as 
>
> machine-name.mat.ucm.es

That might help if the initial sending SMTP server is on your machine
and it is registered in the global DNS (not just an internal only DNS).
It means your machine has a real IP address (not a non-routed address
like 192.168.*.* or 10.*.*.* etc). This would have a higher likelihood
of working if your University still runs its own SMTP server and you are
able to relay through it (some institutions do this to support internal
applications which need to send mail). However, it is very likely the
University will not allow connections out to external SMTP servers
(often, spam is generated by a compromised machine connecting to an SMTP
server and relaying spam etc, so standard practice is to block those
ports). However, it probably won't work if your just connecting to an
external SMTP server (using smtpmail or some other user mail agent).

>
> I am not sure that it will help if I use my Linux SMTP server, [1].
>
> Especially if I am using my laptop on any other institutions or at home,
> since I then will have an IP address that is not within the range of the
> IP addresses my university uses. I could use VPN but that slows down
> things and, it also does not allow me to use newservers since that is
> blocked when using non static university's IP, sigh.

Yes, that is one reason fewer people run their own SMTP server these
days. In addition to all the extra hassles associated with spam
prevention there is the complexity added by being mobile and connecting
via different networks. 

>
> If this approach (registering my machine) does not help, I have to pray
> that google will stick to app passwords for the foreseeable future.
>

One of the reasons this is so hard to work out is because there are just
so many different options and moving parts and the constant need to
evolve and adapt anti-spam measures as the spammers find new loopholes
and ways to circumvent spam prevention. I suspect it is one reason many
organisations have decided to adopt an external service provider and
drop in-house SMTP services.