Re: [ietf-smtp] [Emailcore] Proposed ESMTP keyword RCPTLIMIT

Ned Freed <ned.freed@mrochek.com> Tue, 20 April 2021 17:39 UTC

Return-Path: <ned.freed@mrochek.com>
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 7AC8A3A0DF6 for <ietf-smtp@ietfa.amsl.com>; Tue, 20 Apr 2021 10:39:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mrochek.com
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 AOefuXglozRa for <ietf-smtp@ietfa.amsl.com>; Tue, 20 Apr 2021 10:39:51 -0700 (PDT)
Received: from plum.mrochek.com (plum.mrochek.com [172.95.64.195]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E16B43A0DF8 for <ietf-smtp@ietf.org>; Tue, 20 Apr 2021 10:39:51 -0700 (PDT)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RY3AB3PON4009BC4@mauve.mrochek.com> for ietf-smtp@ietf.org; Tue, 20 Apr 2021 10:34:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mrochek.com; s=201712; t=1618940088; bh=SE6tSlop9WuesWpr3euTW4q/KvBgtOhRGoZNOT0LeZ4=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=RlnzNDLcVVTpsd+OPCB31PmYlXWy5Ux9hX2M/KLWrznUZ5UELSUJPkaCTfSeDIfny a3P0qJVyq+QNyQUZVwo9HdHtPQyAZAAbrPt1VERs0JABZ7pVfa2KPnFxWYqiU+ygZS QzQhOmF8OFZ04O/ga+Vy9tPTM2K1OblQZD7gwFgI=
MIME-version: 1.0
Content-transfer-encoding: 7bit
Content-type: TEXT/PLAIN; CHARSET="us-ascii"
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RY1UKIVTTC0085YQ@mauve.mrochek.com>; Tue, 20 Apr 2021 10:34:46 -0700 (PDT)
Cc: Ned Freed <ned.freed@mrochek.com>, ietf-smtp@ietf.org
Message-id: <01RY3AB1YBI80085YQ@mauve.mrochek.com>
Date: Tue, 20 Apr 2021 10:31:02 -0700
From: Ned Freed <ned.freed@mrochek.com>
In-reply-to: "Your message dated Tue, 20 Apr 2021 16:53:45 +0100" <vQ24SenJkvfgFAH3@highwayman.com>
References: <cone.1615844513.220592.51342.1004@monster.email-scan.com> <20210315234648.563C0708B340@ary.qy> <CAO=DXp-+fJwsNegzu3zgwDLtCcSF104AUF=i+_GMgSYVBAKjWg@mail.gmail.com> <01RY24IJ225Q0085YQ@mauve.mrochek.com> <CAO=DXp-VSxeTsWZFAms7WX-jonkSiyGgKV5T_17VGhq6bcsMdg@mail.gmail.com> <cone.1618877363.380527.55051.1004@monster.email-scan.com> <F8AC11B4-1C30-4DE6-AE70-F91994EE7539@wordtothewise.com> <Dx8j6QnjLufgFAwC@highwayman.com> <01RY347LHNBA0085YQ@mauve.mrochek.com> <vQ24SenJkvfgFAH3@highwayman.com>
To: Richard Clayton <richard@highwayman.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-smtp/v6ckA4y2qiqVnJ3IPRTFAFec-rM>
Subject: Re: [ietf-smtp] [Emailcore] Proposed ESMTP keyword RCPTLIMIT
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: Tue, 20 Apr 2021 17:39:57 -0000

> In message <01RY347LHNBA0085YQ@mauve.mrochek.com>, Ned Freed
> <ned.freed@mrochek.com> writes

> >> as I observed before -- don't expect much more than a generic statement
> >> (which comes down to "sending N good emails is the most you can expect
> >> to be able to manage") from such systems. Anything which revealed the
> >> current view ("actually, you've pretty much exhausted our patience")
> >> just is not going to happen (IMO)
> >
> >I don't really understand the concern here,

> Some bad senders start by sending good email and then, once their
> reputation is established, send bad email. It is generally thought to be
> unwise to give any clues whatsoever as to how well this process might be
> going... (to what extent the machine learning system has been fooled)

> >and more importantly, how to address
> >it.

> It is inherent that you cannot -- so mailbox providers who operate in
> the space where this is a significant issue are not going to provide any
> fine-grained data whatsoever -- just generic values.

That's not what I meant by "address". It's important that standards
discuss all known security issues; and this definitely qualifies.
As such, I'm going to add this text to the Security Considerations:

  Use of the Limits extension to provide client-specific information - as 
  opposed to general server limits - unavoidably provides senders with
  feedback about their reputation. Malicious senders can exploit this
  in various ways, e.g., start by sending good email and then, once their
  reputation is established, sending bad email.

> I take Laura's point that good senders can deduce the upper limits --
> and hence providing data about those upper limits at the start of the
> session has a small amount of value (if only in ensuring that sessions
> close smoothly and fewer exception logging event are generated)

Speaking as someone who works on software used for bulk sending, the the value
isn't small, especially when you take the ability to shape subsequent traffic
into account.

				Ned