[Mailsec] CLIENTID with PIPELINING
Andrew C Aitchison <andrew@aitchison.me.uk> Wed, 15 March 2023 14:52 UTC
Return-Path: <andrew@aitchison.me.uk>
X-Original-To: mailsec@ietfa.amsl.com
Delivered-To: mailsec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCF4BC151531 for <mailsec@ietfa.amsl.com>; Wed, 15 Mar 2023 07:52:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 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, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aitchison.me.uk
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 59DsLLyvXJYq for <mailsec@ietfa.amsl.com>; Wed, 15 Mar 2023 07:52:28 -0700 (PDT)
Received: from mx2.mythic-beasts.com (mx2.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5C59C1522A0 for <mailsec@ietf.org>; Wed, 15 Mar 2023 07:52:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=aitchison.me.uk; s=mythic-beasts-k1; h=Subject:To:From:Date; bh=ZBMxXhhQoekJsQSyuTSy1uZxiy8CIetFU16sac3maNs=; b=YU0ySUgQudSHh0Qob/y+c4ceaH tabiA/1RXWO6rMBwUjjy2/63/Vdk/swi27wBBUuKYS6SGVzOqzhHxlOyT2B5DftT8XcW/cZwFdtVn QfgLSwRLHELEHn5vX8cGO++ZqaX9q5UFP1k9pG/Rpn3UOnmxP7Xugn4o5ZjhfdgKDY8QaE07k1WLB t34GV2OgaAcTLIozaEQnNm7AOVbGfIbGmMnTgZZsUglqWTk0kv/jzzXw4uSLSZah5CtgCj/Rha/dZ zX40u2FKiepZo8fKrIktW4MvNVk7HnmYwwUgaORdd3haguSGLWyx/sK/RFAyWrRIf5vWmTeVrYobm O9mlTqTA==;
Received: by mailhub-hex-d.mythic-beasts.com with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from <andrew@aitchison.me.uk>) id 1pcSUN-003xcE-2l for mailsec@ietf.org; Wed, 15 Mar 2023 14:52:27 +0000
Date: Wed, 15 Mar 2023 14:52:24 +0000
From: Andrew C Aitchison <andrew@aitchison.me.uk>
To: mailsec@ietf.org
Message-ID: <05fa891e-7243-eb2a-d2cc-20c08ca5bbe8@aitchison.me.uk>
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"; charset="US-ASCII"
X-BlackCat-Spam-Score: 0
Archived-At: <https://mailarchive.ietf.org/arch/msg/mailsec/glIvcfOc1_kJEt9hemwG-5TI3QQ>
X-Mailman-Approved-At: Wed, 15 Mar 2023 08:04:36 -0700
Subject: [Mailsec] CLIENTID with PIPELINING
X-BeenThere: mailsec@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Email Security Issues <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: Wed, 15 Mar 2023 14:53:34 -0000
I am attempting to implement CLIENTID for Exim. draft-storey-smtp-client-id-14.txt does not mention pipelining. Would it be reasonable for the next draft to make a statement about whether or not CLIENTID can be pipelined and/or must be synchronised ? The Exim code has: /* RFC3030 section 2: "After all MAIL and RCPT responses are collected and processed the message is sent using a series of BDAT commands" implies that BDAT should be synchronised. However, we see Google, at least, sending MAIL,RCPT,BDAT-LAST in a single packet, clearly not waiting for processing of the RCPT response(s). We shall do the same, and not require synch for BDAT. Worse, as the chunk may (very likely will) follow the command-header in the same packet we cannot do the usual "is there any follow-on data after the command line" even for non-pipeline mode. So we'll need an explicit check after reading the expected chunk amount when non-pipe, before sending the ACK. */ Mad as it may be, Exim also accepts AUTH *when pipelining* - the code has /* I have been unable to find a statement about the use of pipelining with AUTH, so to be on the safe side it is here [in the list of non-sync commands when not pipelining], though I kind of feel it should be up there with the synchronized commands. */ Presumably STARTTLS and CLIENTID commands cannot be sent together, since the CLIENTID must be encrypted, but I would like to at least to know whether or not it is valid for the CLIENTID and AUTH commands to be sent together. As the Exim comments show, if the RFC doesn't forbid it, developers have to allow for it. Thanks, -- Andrew C. Aitchison Kendal, UK andrew@aitchison.me.uk
- [Mailsec] CLIENTID with PIPELINING Andrew C Aitchison
- Re: [Mailsec] CLIENTID with PIPELINING Michael Peddemors
- Re: [Mailsec] CLIENTID with PIPELINING Andrew C Aitchison
- Re: [Mailsec] CLIENTID with PIPELINING Michael Peddemors