Re: gmail+SMTP(only) (oauth2)

[Tim Cross]

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. 

>
> 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).  

>
>     2. Or use a SMTP service that allows me to use a different form
>        field, once the address has been verified. Gmail did this in the
>        past (and maybe still does it).
>

Yes, you will need this. You will likely communicate with this server
using smtpmail. However, in addition to allowing you to set the from
field, you probably also need a service which will handle the SPF and
various other anti-spam headers correctly. This can be very complex and
few services seem to do this correctly. 

Creating such setups when you actually own the email domain is somewhat
easier. Doing it when you are just a client of that domain (as in your
case) is much much more difficult. 

> In any case I have been warned that my mails could be blacklisted.
>

Yes, almost certainly will. The real challenge will be in getting the
various spam prevention schemes to work correctly. This is very
difficult when your using an SMTP server which is not part of the domain
your email appears to come from. When you own the domain, there are
various things you can do with DNS records to allow messages sent via a
different domain, but you don't own the domain and so cannot manage such
records. This would have to be done by the University and they almost
certainly won't be willing to do that. 

> Anybody has experience with such a service/setting?

I have run into this issue for various clients in the past. It is a pain
to get sorted out and you need a really accommodating SMTP service
provider (very difficult to find unless you are willing to fork out real
cash). 

I would check with your institution to see if they would be agreeable to
having a reply-to: header which points to your institutional address
rahter than putting it in the from: header. This would cause less issues
and would still ensure the replies to your messages go through the
University mail system (which is what I'm assuming is the reason for
their request to have their domain as the from line). The downside wiht
reply-to: is that it depends on the message recipient's mail client
honouring that header. While most clients will, some do not. 

I would strongly encourage you to try and use the app password solution.
The alternative you are proposing is possible, but is not for the faint
hearted and requires significant deep understanding of both SMTP and the
various evolving spam prevention frameworks as well as an SMTP service
partner who actually has the in-house expertise to run a correctly
configured and maintained SMTP server.   

Bottom line: the app passwords solution 'just works'. Just generate the
app passwords and use them instead of your normal password for imap and
smtp. The altgernative you are proposing will be unlikely to work 100%,
will require on-going maintenance and will likely be fragile and result
in a higher percentage of your messages being blocked or quarantined.