After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 764211 - Outgoing mail not encrypted
Outgoing mail not encrypted
Status: RESOLVED OBSOLETE
Product: sysadmin
Classification: Infrastructure
Component: Mailman
unspecified
Other All
: Normal normal
: ---
Assigned To: GNOME Sysadmins
GNOME Sysadmins
Depends on:
Blocks:
 
 
Reported: 2016-03-25 21:27 UTC by Morten Welinder
Modified: 2018-09-21 15:25 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Morten Welinder 2016-03-25 21:27:47 UTC
Google has started flagging mail sent in plain text over the wire, i.e.,
without transport layer encryption.

Gnome mailing lists, notably gtk-devel, appear to be sent in cleartext.
It's not particularly secret, but all mail really ought to be encrypted
on the wire at this point in time.

Suggestion: encrypt.
Comment 1 Andrea Veri 2016-04-28 15:57:53 UTC
Gmail's red lock is there for two main reasons:

1. DKIM missing on the gnome.org domain
2. SMTP server used by the GNOME contributor not supporting TLS

As of today the GNOME Infrastructure does not provide an SMTP server for relaying outbound e-mails, what we do is serving a set of aliases which a remote mail server can query. Once smtp.gnome.org has been queried, the e-mail the alias forwards to is returned, from there smtp.gnome.org effectively sends the e-mail.

What happens for inbound e-mails:

@gnome.org alias owner mail client - (TLS, if supported)> @gnome.org alias owner mail server - (TLS, if the local server requests it) ->  smtp.gnome.org - (TLS, if supported by recipient's mail server)> recipient mail server

What smtp.gnome.org didn't have before today:

1. Inbound TLS (mails between an external SMTP server and smtp.gnome.org weren't encrypted, ever). What we do now is instead supporting STARTTLS, it's then up to the external mail server to STARTTLS or not.
2. Outbound TLS (no SASL involved as we don't offer any SMTP relaying service) for e-mails that are sent from an external mail server to a @gnome.org mail alias. When the remote mail server reaches smtp.gnome.org, the aliases table is evaluated and from there smtp.gnome.org is able to STARTTLS if the remote mail server is configured to do so. For a certain set of domains we plan to encrypt e-mails by default, the list currently only includes gmail.com. If you have more suggestions please let us know. 

Why the red lock isn't going to disappear even after increasing smtp.gnome.org's security? As reported above we don't offer DKIM as @gnome.org alias owners do use their own SMTP servers as of today which prevents us to include DKIM signatures on the outgoing e-mails. Our mail server security has however been secured with the improvements listed above.

Thanks for your report!
Comment 3 GNOME Infrastructure Team 2018-09-21 15:25:30 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/Infrastructure/Infrastructure/issues/12.