TLS padlock for received emails

[ridem]

A few weeks ago, Gmail introduced a new padlock next to received e-mails to tell if TLS has been used by the sender. If not, a red padlock appears. More info: http://mashable.com/2016/02/13/gmail-encryption/

In the Raw source, it's a line in the "Received" Header that goes like this: (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);

They also have that feature for emails you're about to send, but they're caching domains and previous email exchanges with them to give the information, it would require way more work.

I guess this could be in a core plugin (inside phishing detector, renamed?) If it's in line with the project I could give it a try with a PR.

[emorikawa]

That sounds like a great plugin idea & definitely in line with what we want. You can probably make that a stand alone plugin easily. The Phishing one would be a great piece of code to copy to get started. Happy to help out as well.

[mbilker]

@emorikawa Is the necessary information for the Header information available through the local Database? Would the plugin need to make an API request to receive the raw message and parse it to check each step used TLS to send the message?

[mbilker]

This sounds like an interesting plugin I could develop.

[ridem]

Cool! I can have a look at it when I have time then, the phishing plugin seems perfect to start off with.

NB @emorikawa : I think it would be a great improvement to the Nylas infrastructure to gather per-domain TLS stats out of sent messages raw data, you guys would get a huge and very valuable database. It would be useful for N1 users to know in advance if TLS will be used, but I guess there would even more service potential than that.

[ridem]

@mbilker : We could join forces if you want! ;)

[ridem]

@mbilker : It's possible through the API (https://www.nylas.com/docs/#raw_message_contents) but I guess it's not part of the local database, because the only place it's used in the code is at: https://github.com/nylas/N1/blob/master/internal_packages/message-list/lib/message-controls.cjsx#L116

I now understand why the phishing plugin does so little (no DKIM / SPF checks on the source) because reply_to & co. is the only thing it can use from the local database.

[mbilker]

@ridem I knew about that because that feature is available if you click on the space the left of the reply button. I prefer to not do an API request and have N1 handle it or store all of the information locally.

[mbilker]

Good to know though!

[ridem]

@mbilker yeah I actually found that feature by looking at the code, nice one.

And I agree that grabbing the whole raw source again and doing the parsing from the client is not clean at all. Getting an API feature to request a few additional headers would be awesome, there are so many things you could do with it for suspicious messages detection (DKIM, SPF, etc.), or unsubscribe to newsletters with "List-Unsubscribe".