IETF Logo Mail Archive

Re: [ietf-smtp] Possible contribution to moving forward with RFC5321bis SMTP

Viktor Dukhovni <ietf-dane@dukhovni.org> Wed, 01 January 2020 18:06 UTC

Return-Path: <ietf-dane@dukhovni.org>
X-Original-To: ietf-smtp@ietfa.amsl.com
Delivered-To: ietf-smtp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C7C91200A4 for <ietf-smtp@ietfa.amsl.com>; Wed, 1 Jan 2020 10:06:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9PL0FgvVlNxO for <ietf-smtp@ietfa.amsl.com>; Wed, 1 Jan 2020 10:06:26 -0800 (PST)
Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03F9C1200A1 for <ietf-smtp@ietf.org>; Wed, 1 Jan 2020 10:06:24 -0800 (PST)
Received: from [192.168.1.161] (unknown [192.168.1.161]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by straasha.imrryr.org (Postfix) with ESMTPSA id A357D2A79D4 for <ietf-smtp@ietf.org>; Wed, 1 Jan 2020 13:06:22 -0500 (EST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\))
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
In-Reply-To: <20200101175510.8549A11E2905@ary.qy>
Date: Wed, 01 Jan 2020 13:06:20 -0500
Content-Transfer-Encoding: 7bit
Reply-To: ietf-smtp@ietf.org
Message-Id: <D441E0BE-1F32-4329-9296-A5026540E8D0@dukhovni.org>
References: <20200101175510.8549A11E2905@ary.qy>
To: ietf-smtp@ietf.org
X-Mailer: Apple Mail (2.3608.40.2.2.4)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-smtp/HBUqlbiYAVcHULkukcNzUQpB3p0>
Subject: Re: [ietf-smtp] Possible contribution to moving forward with RFC5321bis SMTP
X-BeenThere: ietf-smtp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussion of issues related to Simple Mail Transfer Protocol \(SMTP\) \[RFC 821, RFC 2821, RFC 5321\]" <ietf-smtp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf-smtp>, <mailto:ietf-smtp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf-smtp/>
List-Post: <mailto:ietf-smtp@ietf.org>
List-Help: <mailto:ietf-smtp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf-smtp>, <mailto:ietf-smtp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 01 Jan 2020 18:06:28 -0000

> On Jan 1, 2020, at 12:55 PM, John Levine <johnl@taugh.com> wrote:
> 
> But once again, this is submission, not SMTP.  A client certificate is
> a plausible way for a submission client to authenticate itself to the
> submission server.

Well, I think what Keith was hinting at is that in some idealized Internet
we don't have, "real" SMTP clients could be authenticated via client certs,
making it harder for botnets (on machines that lack such certs) to be seen
as real SMTP clients.

Of course the bad guys can register a new domain for $5/year, get a Let's
Encrypt cert, and have the botnet use that domain and cert for a few hours,
and then register another domain...   So I don't see how client certs would
in fact keep abuse at bay.

-- 
	Viktor.

v2.23.0 | Report a Bug | By Email