Your Emails Are Not Secure! (And What You Can Do About It)

[@ProTechShow]

Another way to secure your emails is to make sure they can't be spoofed: kzbin.info/www/bejne/iKWno4Kpndl5n6s

[@andrew.schaeffer4032]

love the video - explaining concepts in plain english. I've read Google's instructions on setting up MTA-STS and wish you had written them XD

[@ProTechShow]

Haha! Cheers 🙂

[@kumarnair143]

Good One.. very easy to Understand. Thank you :)

[@ProTechShow]

Thanks

[@rajashahbaz3441]

Thank you for sharing this knowledge. Please make a video on E2E encryption.

[@ProTechShow]

I'll add it to the ideas list, thanks!

[@talasilajayanth]

Love watching all your videos

[@ProTechShow]

Thanks 🙂

[@blastedoak42]

Really interesting. Thanks.

[@ProTechShow]

You're welcome 🙂

[@arbilus5296]

Hello, do we need to use Mta Sts if we configure connectors to use the "RequireTLS" option, please ? (I'm speaking about Exchange Server)

[@ProTechShow]

You don't have to use MTA-STS, but it is another security improvement you can add to your list.

[@arbilus5296]

@Pro Trch Show thanks for the answer. Then I don't understand what's the difference between activating the "RequireTls" option and using MTA STS. If RequireTLS ensure the use of TLS and not StartTLS then there is no issue with possible MITM attacks which could remove the 250 STARTTLS and then MTA STS is useless, no ?

[@ProTechShow]

@@arbilus5296 enforcing TLS on your receive connector won't prevent MitM because the sender only becomes aware of your enforcement once they've connected to your server. If someone positions themselves in the middle they can offer plaintext to the sender and that's all they will see. Your RequireTLS setting only forces the attacker to connect securely to you if they want to pass the message on. If you had MTA-STS set up then the sender could see your policy to require authenticated TLS before they attempted a connection and would refuse to use the MitM service that didn't match your MTA-STS policy.

[@mohadesefakharnezhad6228]

Be aware of the risks and choose trusted communication and data apps. I communicate in the Utopia ecosystem (uMail) and I am not afraid that my personal data will get to third parties.

[@shaikimran3196]

What's a certificate? I heard about it with website, servers, apps or programs etc I am aware that you made video about ssl cert but what is a certificate basically. Is it a file or some sort of verification. How many kinds of them are there (including certs used for apps and so onn)

[@ProTechShow]

It's a topic by itself to cover encryption and digital signatures, but... Usually, they're stored as files or a registry value - but data either way. They can be used for many purposes, but generally speaking they provide proof of identity, proof data hasn't been changed, and a key that can be used to send encrypted data to the owner of the certificate. For a website you'd use it to prove the identity of the website and to encrypt your connection to it. With software you'd use it to prove the author of the software and that it hasn't been tampered with. With email you'd use it to encrypt an email and/or prove the identify of the sender.

[@shaikimran3196]

@@ProTechShow thank you❤️

[@harrytrueman4216]

Is email decreasing with the rise of teams and slack and do they use end to end encryption. What's your thoughts tech companies forcing parler out? A case for on prem?

[@ProTechShow]

Many a person has declared email dead over the years, but so far its use grows year-on-year. I'll believe it when I see it! Instant messaging serves a different use case, so I think we'll see both continue. The other big difference is that email is completely interoperable and has no vendor lock-in. I can move my mailbox from Microsoft to Google and it'll keep working and keep communicating with anyone on any platform. If you try to do the same Teams to Slack then keeping your data intact will be a nightmare and you can't talk to anyone on a different service (with some exceptions).

[@ProTechShow]

TBH I haven't been following the Parler stuff very closely. My biggest surprise is that people are surprised. If you use someone else's platform you play by their rules. There are plenty of other places to go... whether on-prem or cloud. I don't think it'll bother most companies as they're not likely to cause AWS a PR headache. If going full cloud it's not a bad idea to have a backout plan just in case, though. This scenario might not be likely to affect the average person, but what if AWS cranked the price up significantly? It's always useful to have a plan B so no one vendor can bend you over a barrel.

[@stacyhackney6100]

Thank you

[@ProTechShow]

You're welcome

[@salvatore_gareggio]

Ciao ti scrivo dall'Italia. Ho guardato il video ed è molto interessante. Purtroppo il problema della crittografia della posta elettronica è annoso. In Italia esiste però un' alternativa, si chiama PEC ovvero posta elettronica certificata ed è soggetta a rigorosi controlli ed ha garanzia legale. Però entrambe le caselle devono essere 'certificate' . Conosci questo tipo di posta elettronica? 🙂

[@ProTechShow]

Hello. Interesting. I haven't come across that over here yet. I suspect interoperability would be a barrier to adoption. Technologies like MTA-STS and TLS are backwards compatible with traditional email, whereas it sounds like PEC only talks to PEC and there are a limited number of approved providers to choose from. Is it being promoted by the Italian government? It feels like something that would need to achieve a certain critical mass before people would be likely to use it over here.

[@salvatore_gareggio]

@@ProTechShow Si è giusto. Per poter funzionare entrambe le caselle devono essere 'PEC". Tuttavia tieni presente che gli standard di sicurezza sono elevati di conseguenza garantiscono che il messaggio sia inalterabile, protetto ed arrivi con certezza nella casella di destinazione perché i provider invia due ricevute di accettazione ed avvenuta consegna. Lo so che fuori dall'Italia non esiste questa cosa ma se tutti la adottassero saremmo più sicuri da occhi indiscreti.