[Mailsec] new Non-WG Mailing List: mailsec
IETF Secretariat <firstname.lastname@example.org> Mon, 15 June 2020 20:49 UTC
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E5293A0D41; Mon, 15 Jun 2020 13:49:00 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
From: IETF Secretariat <email@example.com>
To: "IETF Announcement List" <firstname.lastname@example.org>
Cc: email@example.com, firstname.lastname@example.org, email@example.com
Date: Mon, 15 Jun 2020 13:49:00 -0700
Subject: [Mailsec] new Non-WG Mailing List: mailsec
List-Unsubscribe: <https://www.ietf.org/mailman/options/mailsec>, <mailto:firstname.lastname@example.org?subject=unsubscribe>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mailsec>, <mailto:email@example.com?subject=subscribe>
X-List-Received-Date: Mon, 15 Jun 2020 20:49:00 -0000
A new IETF non-working group email list has been created. List address: firstname.lastname@example.org Archive: https://mailarchive.ietf.org/arch/browse/mailsec/ To subscribe: https://www.ietf.org/mailman/listinfo/mailsec Purpose: This list is for discussion of how to address serious issues affecting the Internet community's use of email, and to develop consensus on strategies that can effectively protect Internet email users from threats, and to develop recommendations and standards where the IETF can have a role, from developing white papers, standards and changes or additions to existing RFCs. Example topics might include how to mitigate email compromises, and prevent the transmission of plain text credentials in the clear, and the topics should clearly be aligned to an existing persistent threat in the email eco-system, rather than theoretical improvements to email itself. A compromised email account for instance, is still one of the world's largest threats, and no longer just an excuse for someone to spam from the person's email accounts. Today, a compromise is used for much more serious harm, such as reading your email, stealing your contacts, or taking over internet assets where your email address is trusted: stealing your domain name, taking over your bank account, spear phishing your boss, or just spreading malware and ransomware to those who trust you. As a community, we understand their are things that can be done, however many ideas are not yet set as standards, and in some cases are still enshrined by existing RFCs that might be overdue for a review. Ideas for conversation(s): * Should we formally deprecate plaintext ports POP 110 and SMTP 25? * How can we prevent/report/mitigate BRUTE FORCE attacks? (Industry Initiatives, targeting the sources) * Use cases for the CLIENTID proposal in SMTP/IMAP for mitigating threats. -- TOKEN possibilities as an ACL -- Offering CLIENTID pass through to legacy AUTH and SASL methods * Case studies on other transparent two-factor authentication approaches. * We don't always need the perfect solution, but what can we adopt today as a community, that would immediately make a difference? * Best practices at egress for large email providers. * Hosting providers and detecting AUTH attacks on egress. * IoT email AUTH attack proliferation. This list belongs to IETF area: TSV For additional information, please contact the list administrators.
- [Mailsec] new Non-WG Mailing List: mailsec IETF Secretariat