Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!


Forced TLS Encryption for email.
New on LowEndTalk? Please Register and read our Community Rules.

All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.

Forced TLS Encryption for email.

Can someone give me a rundown on PROs and Cons of Forced TLS Encryption for email ?

Comments

  • Pros: Encryption

    Cons: Encryption

    Thanked by 3Aluminat Aidan FHR
  • @WSS said:
    Pros: Encryption

    Cons: Encryption

    That was insightful hehe
    From what I read, it sounded like if the email server is set to forced TLS then it will only send/received emails from other mail servers that use forced TLS.

    This can't be right, is it?

  • My fear is always that they will be intercepted. For example if I send an email asking a woman to marry me, and I get an intercepted email back saying "yes", when it would have been no. Then I would be standing there with the band and caterers having wasted my money.

  • FrankZFrankZ Veteran
    edited February 2018

    IMHO, If you are sending sensitive info via email between parties that all use encryption capable email servers then forced encryption send/receive is the way to go.

    For general email
    1. I would not set my servers to send forced TLS encryption as they will send encrypted if the option is available at the receiving mail server by default.
    2. I would not set my mail servers to only receive encrypted email since I would not get email from some mail servers that are not TLS capable.

    @404error said: From what I read, it sounded like if the email server is set to forced TLS then it will only send/received emails from other mail servers that use forced TLS.

    It will only send/received emails from/to other mail servers that are TLS capable, does not need to be forced.

    Thanked by 4404error WSS coreflux FHR
  • @FrankZ said:

    @404error said: From what I read, it sounded like if the email server is set to forced TLS then it will only send/received emails from other mail servers that use forced TLS.

    It will only send/received emails from/to other mail servers that are TLS capable, does not need to be forced.

    So basically I will be risking not receiving some email, I wonder if nowadays, email server are not by default TLS capable. Thus minimizing that risk.

    From what I read, big players since a few years back to today, decided to move to be TLS capable, as opposed to being against implementing it.
    So I wonder if TLS capable is the norm now, which would mean that forced TLS was virtually riskless.

    Any personal experience?

    Thanked by 1FHR
  • @Ole_Juul said:
    My fear is always that they will be intercepted. For example if I send an email asking a woman to marry me, and I get an intercepted email back saying "yes", when it would have been no. Then I would be standing there with the band and caterers having wasted my money.

    This here is why I always exchange encryption keys before marriage proposals.

  • FrankZFrankZ Veteran
    edited February 2018

    Are modern MTA's TLS capable? I am sure there are exceptions, but in regard to what I think you are asking, I would say yes. The problem is just because a MTA is TLS capable it does not mean that everybody will get a cert and set up a proper TLS mailserver.

    Thanked by 1coreflux
  • @FrankZ said:
    Are modern MTA's TLS capable? I am sure there are exceptions, but in regard to what I think you are asking, I would say yes. The problem is just because a MTA is TLS capable it does not mean that everybody will get a cert and set up a proper TLS mailserver.

    With let's encrypt, there's no reason not to secure your mailserver

  • Not sure if my memory serves me right here but isn't optional TLS handled by advertizing a STARTTLS command or something like that making optional TLS completely broken since anyone man-in-the-middling the connection could simply suppress the advertizement and thereby forcing the connection to fall back on cleartext? Likewise anyone spoofing the server could just avoid having to present a certificate by pretending to not support TLS. If i am right here that means unless you force TLS you can as well spare yourself the work of setting it up at all.

  • @Ych said:

    @FrankZ said:
    Are modern MTA's TLS capable? I am sure there are exceptions, but in regard to what I think you are asking, I would say yes. The problem is just because a MTA is TLS capable it does not mean that everybody will get a cert and set up a proper TLS mailserver.

    With let's encrypt, there's no reason not to secure your mailserver

    but how many people makes own mailserver?

  • mksh said: isn't optional TLS handled by advertizing a STARTTLS command

    You are correct.

    mksh said: making optional TLS completely broken since anyone man-in-the-middling the connection could simply suppress the advertizement and thereby forcing the connection to fall back on cleartext? Likewise anyone spoofing the server could just avoid having to present a certificate by pretending to not support TLS. If i am right here that means unless you force TLS you can as well spare yourself the work of setting it up at all.

    Forcing TLS on the receiving end mail server will not prevent the above if the sending mail server is not set to force TLS

  • @FrankZ said:
    Forcing TLS on the receiving end mail server will not prevent the above if the sending mail server is not set to force TLS

    Why not? If one server insists on using TLS the connection will just be terminated. No way to force a delivery in cleartext or avoid exchanging certs or am i missing something here?

  • FrankZFrankZ Veteran
    edited February 2018

    mksh said: Why not? If one server insists on using TLS the connection will just be terminated. No way to force a delivery in cleartext or avoid exchanging certs or am i missing something here?

    If I understand your example above correctly both the sending and receiving mail servers in your example are not under your control. The intended receiving mail server, which is under your control, was never contacted, so its settings should not make any difference. I may be wrong, but as far as I know there is no way for a sending email server to know that a receiving email server is forced TLS before it contacts it, so as to avoid being spoofed or MiM'ed in the way you described.

    Edit: Your right, MiM "could" happen and email would not fail on non forced, and would fail on forced TLS

  • FrankZFrankZ Veteran
    edited February 2018

    A handy tool to help check that your forced/optional TLS mail server is setup correctly.

  • rm_rm_ IPv6 Advocate, Veteran
    edited February 2018

    There is not much benefit in using TLS if certs are all self-signed anyway. And it is almost the norm to use a self-signed cert for a mail server, and tell it not to care if other servers do. This is not HTTPS. If you force encryption and force requiring valid cert from others, you will not be able to send or receive a large portion of all mail.

    Thanked by 1FrankZ
  • jarjar Patron Provider, Top Host, Veteran

    @Ole_Juul said:
    My fear is always that they will be intercepted. For example if I send an email asking a woman to marry me, and I get an intercepted email back saying "yes", when it would have been no. Then I would be standing there with the band and caterers having wasted my money.

    Sometimes you read a story so unusually specific that you're pretty sure the writer lived it.

    Sorry for your loss.

    Thanked by 1Ole_Juul
  • jarland said: Sorry for your loss.

    Good one. :) I'm actually quite lucky to have had several good weddings in my life and the finest relationship in my old age. In fact trust has never been an issue for me, which is perhaps why I tend toward being skeptical of the often professed ubiquitous need for encrypted mail. Good for legal matters perhaps, and privacy for sure, but not especially useful in much personal communications.

Sign In or Register to comment.