Hello Slackbuilders! We have signed the slackbuilds.org DNS zone now. DNSSEC-validating resolvers will see valid signatures on every record in our zone.
Also, we have implemented RFC 7672 (and related) for DANE authentication via SMTP: https://tools.ietf.org/html/rfc7672 https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Named_Entities What this means in a nutshell is that if you are sending to us from/through a DANE-enabled MTA, your TLS connections are fully authenticated and secured. This includes addresses both @slackbuilds.org and @lists.slackbuilds.org. DANE for SMTP is a fully client-side protocol. This *only* helps secure connections TO us to send mail to us. We have used client DANE support for outgoing mail for many years, BTW. For @slackbuilds.org email users, nothing has changed. You still will see the Let's Encrypt certificate when using your MUA to send mail on port 587 or to receive mail via IMAP. Port 25, however, is using a new certificate from our own private SSL-CA (certificate authority.) The frequent expiration of LE certificates is a problem for DANE. Plus, one of the advantages of DANE is that we don't need an external CA to vouch for us. We have allowed you to verify our CA through our signed DNS records. DANE support in other protocols is a long way off, but it's already implemented for SMTP in two popular MTAs (Postfix and Exim.) DANE *is NOT* a substitute for GnuPG, S/MIME, or other end-to-end email encryption methods. System admins at both ends have the ability to "snoop" on unencrypted mail. What DANE does is limit snoopability and prevent "man-in-the-middle" attacks. -- Rob McGee - /dev/rob0 - r...@slackbuilds.org _______________________________________________ SlackBuilds-users mailing list SlackBuilds-users@slackbuilds.org http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/ FAQ - https://slackbuilds.org/faq/