email server secured data communication state of the art

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

email server secured data communication state of the art

Thomas-4
Hello,
how can I check whether the recipient / operator of an email server
where I send email also operates one that offers it at all?
Respectively. what is the state of the art that he should use / offer?

Comments are e.g. that look more like "make me important" from the
manager "from such operators:
".... matter that communication has chosen the unencrypted e-mail
communication with all its dangers ..."

Thanks
Thomas
Reply | Threaded
Open this post in threaded view
|

Re: email server secured data communication state of the art

Jaroslaw Rafa
Dnia 16.01.2020 o godz. 18:03:29 Thomas pisze:
> Hello,
> how can I check whether the recipient / operator of an email server
> where I send email also operates one that offers it at all?
> Respectively. what is the state of the art that he should use / offer?
>
> Comments are e.g. that look more like "make me important" from the
> manager "from such operators:
> ".... matter that communication has chosen the unencrypted e-mail
> communication with all its dangers ..."

But what exactly is your question? What do you actually ask? Because it's
hard to understand...
--
Regards,
   Jaroslaw Rafa
   [hidden email]
--
"In a million years, when kids go to school, they're gonna know: once there
was a Hushpuppy, and she lived with her daddy in the Bathtub."
Reply | Threaded
Open this post in threaded view
|

Re: email server secured data communication state of the art

Viktor Dukhovni
In reply to this post by Thomas-4
On Thu, Jan 16, 2020 at 06:03:29PM +0100, Thomas wrote:

> How can I check whether the recipient / operator of an email server
> where I send email also operates one that offers it at all?
> Respectively. what is the state of the art that he should use / offer?

The answer is a matter of taste.  I think it is safe to say that support
STARTTLS (with TLS 1.2 and perhaps also TLS 1.3) is now expected
best-practice behaviour.  Just TLS 1.0 (or 1.1) are likely to soon if
not already encounter interoperability issues as operators start to
phase out these now deprecated TLS versions.  Beyond that,

    * Many will recommend DKIM and SPF.  I am not a fan of these, but
      I grudgingly added SPF to reduce some friction.  Some will also
      strongly recommend DMARC, which I personally find particularly
      objectionable.

    * I'd like to recommend DNSSEC and DANE to secure inbound email,
      and there is noticeable support and momentum behind this in
      Northern Europe.  However, overall support for DNSSEC and DANE
      is still the exception and not the rule.

        https://stats.dnssec-tools.org/
        https://mail.sys4.de/pipermail/dane-users/2020-January/000546.html

      Please deploy DNSSEC and DANE, but these are not suitable as a
      fire and forget fashion statement.  They take some operational
      dilligence to implement correctly, with monitoring and carefully
      thought out key rollover processes a must.

        https://mail.sys4.de/pipermail/dane-users/2018-February/000440.html
        https://github.com/internetstandards/toolbox-wiki/blob/master/DANE-for-SMTP-how-to.md
        https://community.letsencrypt.org/t/please-avoid-3-0-1-and-3-0-2-dane-tlsa-records-with-le-certificates/7022/17
        https://mail.sys4.de/pipermail/dane-users/2017-August/000417.html
        https://github.com/baknu/DANE-for-SMTP/wiki/2.-Implementation-resources

     * To secure inbound email from Google, Microsoft, et. al, you could
       also implement MTA-STS, which like DANE also requires some care
       and feeding.  Don't to it unless you can do it right.

--
    Viktor.
Reply | Threaded
Open this post in threaded view
|

Re: email server secured data communication state of the art

Anton Rieger
On Thu, Jan 16, 2020 at 12:51:18PM -0500, Viktor Dukhovni wrote:
>On Thu, Jan 16, 2020 at 06:03:29PM +0100, Thomas wrote:
>
>> How can I check whether the recipient / operator of an email server
>> where I send email also operates one that offers it at all?
>> Respectively. what is the state of the art that he should use / offer?
Please also consider RFC8314[2]
>
>The answer is a matter of taste.  I think it is safe to say that support
>STARTTLS (with TLS 1.2 and perhaps also TLS 1.3) is now expected
>best-practice behaviour.  Just TLS 1.0 (or 1.1) are likely to soon if
>not already encounter interoperability issues as operators start to
>phase out these now deprecated TLS versions.  Beyond that,
I'd agree to that.
>
>    * Many will recommend DKIM and SPF.  I am not a fan of these, but
>      I grudgingly added SPF to reduce some friction.  Some will also
>      strongly recommend DMARC, which I personally find particularly
>      objectionable.
Could you elaborate a bit about 'why'?

>    * I'd like to recommend DNSSEC and DANE to secure inbound email,
>      and there is noticeable support and momentum behind this in
>      Northern Europe.  However, overall support for DNSSEC and DANE
>      is still the exception and not the rule.
Just wanted to add that some TLDs are not supporting DNSSEC (yet).
>
>        https://stats.dnssec-tools.org/
>        https://mail.sys4.de/pipermail/dane-users/2020-January/000546.html
>
>      Please deploy DNSSEC and DANE, but these are not suitable as a
>      fire and forget fashion statement.  They take some operational
>      dilligence to implement correctly, with monitoring and carefully
>      thought out key rollover processes a must.
+1

>
>        https://mail.sys4.de/pipermail/dane-users/2018-February/000440.html
>        https://github.com/internetstandards/toolbox-wiki/blob/master/DANE-for-SMTP-how-to.md
>        https://community.letsencrypt.org/t/please-avoid-3-0-1-and-3-0-2-dane-tlsa-records-with-le-certificates/7022/17
>        https://mail.sys4.de/pipermail/dane-users/2017-August/000417.html
>        https://github.com/baknu/DANE-for-SMTP/wiki/2.-Implementation-resources
>
>     * To secure inbound email from Google, Microsoft, et. al, you could
>       also implement MTA-STS, which like DANE also requires some care
>       and feeding.  Don't to it unless you can do it right.
 From the RFC 8461[1]
     »SMTP MTA Strict Transport Security (MTA-STS) is a mechanism enabling
     mail service providers (SPs) to declare their ability to receive
     Transport Layer Security (TLS) secure SMTP connections and to specify
     whether sending SMTP servers should refuse to deliver to MX hosts
     that do not offer TLS with a trusted server certificate.«

Just to give an overview what MTA-STS is.

Greetings

[1] https://tools.ietf.org/html/rfc8314
[2] https://tools.ietf.org/html/rfc8461