Re: gmail+SMTP(only) (oauth2)

[Tim Cross <theophilusx@gmail.com>]

Richard Stallman <rms@gnu.org> writes:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>   > 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
>
>   >     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).
>
>   > In any case I have been warned that my mails could be blacklisted.
>
> That is rather unclear.  Do you mean that
> (1) if you fail to have the right From field, your emails could
> be blocked, or
> (2) regardless of the From field, your emails could be blocked?

This is all related to various spam prevention schemes used by SMTP
servers these days. In a nutshell, there are various widely used schemes
which verify the IP address and/or domain of the originating SMTP server
is part of or associated with the domain in the from header address.
This is often achieved based on DNS records, such as an MX record. 

The result is, if there isn't some verifiable relationship between the
SMTP server and the domain in the from header, it is likely the message
will be blocked by many SMTP servers. The matter is made worse in that
many of the SMTP servers which will allow you to set an arbitrary domain
in your from header are already considered suspect as these are also
often servers legitimately associated with sending spam. Many SMTP
servers won't allow you to set an arbitrary from header or will only
allow you to set the header to a specific domain based on your IP
address. 
 
Just to try and be clear for the very last time here. There is NO 100%
free/libre solution to using gmail for email. There are some solutions
which will minimise the amount/frequency of need to use non-free/libre
software, but none which eliminate it. However, adopting Google as the
email provider for an organisation does NOT mean the organisation uses
Google's 'standard' gmail authentication/authorisation infrastructure. Often,
especially for larger organisations, the organisations own identity
management infrastructure will be used. Unfortunately, few identity
management solutions are free/libre and only a handful exist which are
classified as open source. This means there is no solution which will
work across the board. Each organisation will need to be assessed
individually. 

Using Google to host your email services is NOT the same as using
Google's gmail service. When an organisation announces they will be
moving their email service to google, you cannot assume this will mean
it is going to be equivalent to Google's gmail service. (same holds for
organisations which adopt Office365 as their email service provider).
Therre will likely be some commonality, but there could also be
significant differences.  

Technically, email can be forwarded to a different service. This is an
optional feature which may or may not be allowed by the owning
organisation. Most organisations will not permit this and it is an
option which is generally discouraged by most security professionals.
Even when allowed, it tends not to work well due to the way modern spam
prevention techniques work. 

If an organisation adopts Google as their email service provider, it is
not equivalent to using gmail as your email service provider. While the
data may use/share some of the same physical infrastructure, the
policies and procedures, as well as the authentication and authorisation
processes, can be significantly different.  

If you are using 'real' gmail, you can minimise your use of
non-free/libre software by setting up application passwords. This only
needs to be setup once and after that, you can use whatever SMTP and
IMAP client you want. It is likely Google will remove application
password support at some point in the future, but at this time, they
have not flagged any definite plans to do this. It would be expected
they will provide a significant transition period if and when such plans
are announced. 

Application passwords may or may not be available with organisations
which use Google to host their email services. This will depend on the
policies of the organisation, the level of integration and the
authentication/authorisation approach adopted by the organisation.