[Mailsec] new Non-WG Mailing List: mailsec

IETF Secretariat <ietf-secretariat@ietf.org> Mon, 15 June 2020 20:49 UTC

Return-Path: <ietf-secretariat@ietf.org>
X-Original-To: mailsec@ietf.org
Delivered-To: mailsec@ietfa.amsl.com
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)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: IETF Secretariat <ietf-secretariat@ietf.org>
To: "IETF Announcement List" <ietf-announce@ietf.org>
Cc: aamelnikov@fastmail.fm, michael@linuxmagic.com, mailsec@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 7.3.1
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: ietf@ietf.org
Message-ID: <159225414010.20572.15936256756428139294@ietfa.amsl.com>
Date: Mon, 15 Jun 2020 13:49:00 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/mailsec/scv5RTIftHqof_snfB5O9cPAtKY>
Subject: [Mailsec] new Non-WG Mailing List: mailsec
X-BeenThere: mailsec@ietf.org
X-Mailman-Version: 2.1.29
List-Id: <mailsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mailsec>, <mailto:mailsec-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mailsec/>
List-Post: <mailto:mailsec@ietf.org>
List-Help: <mailto:mailsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mailsec>, <mailto:mailsec-request@ietf.org?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: mailsec@ietf.org
Archive: https://mailarchive.ietf.org/arch/browse/mailsec/
To subscribe: https://www.ietf.org/mailman/listinfo/mailsec

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.