Re: [ietf-smtp] SMTP server reply extensions

Valdis Kl ē tnieks <valdis.kletnieks@vt.edu> Fri, 10 April 2020 00:34 UTC

Return-Path: <valdis@vt.edu>
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 E295B3A17A0 for <ietf-smtp@ietfa.amsl.com>; Thu, 9 Apr 2020 17:34:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 g2VFn1a-mpHU for <ietf-smtp@ietfa.amsl.com>; Thu, 9 Apr 2020 17:34:17 -0700 (PDT)
Received: from omr1.cc.vt.edu (omr1.cc.ipv6.vt.edu [IPv6:2607:b400:92:8300:0:c6:2117:b0e]) (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 B42703A1796 for <ietf-smtp@ietf.org>; Thu, 9 Apr 2020 17:34:17 -0700 (PDT)
Received: from mr6.cc.vt.edu (mr6.cc.ipv6.vt.edu [IPv6:2607:b400:92:8500:0:af:2d00:4488]) by omr1.cc.vt.edu (8.14.4/8.14.4) with ESMTP id 03A0YGhG021069 for <ietf-smtp@ietf.org>; Thu, 9 Apr 2020 20:34:16 -0400
Received: from mail-qv1-f69.google.com (mail-qv1-f69.google.com [209.85.219.69]) by mr6.cc.vt.edu (8.14.7/8.14.7) with ESMTP id 03A0YBU3016973 for <ietf-smtp@ietf.org>; Thu, 9 Apr 2020 20:34:16 -0400
Received: by mail-qv1-f69.google.com with SMTP id a7so363123qvm.21 for <ietf-smtp@ietf.org>; Thu, 09 Apr 2020 17:34:16 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:to:cc:subject:in-reply-to:references :mime-version:content-transfer-encoding:date:message-id; bh=yHeFQMsZP/JvsfQ/3focsF6YWa1DXNt9PQOLQ48oGrQ=; b=JbaYEOFOLLuZ8hIis+Q5cxKL4nAtFuIE9007keGxXpoByI7qDgeXsNTfwFd+ExM/AX 82zzVqRVn981nD1Dg/5jv5anZ8Oh71XAOnutjdG5QKW8e9EuY7MeePvArXdvJaaeFvnu 665JakLPvnljFUpRORYaotD5tOxKJLukNh1NAKMP8cQeADuWd7L/gBACAKJugcVP8L6c YC8b90RIl/fIZS1c6dPUvJAoGngRJQAQGky6A+NJz8YKTbHLvU3rtMu02A/MLFnA5ofw eiuuGkvzJC3/EKFpC6S4ADywUKjrR0bBKcON87a6Iame0HDvcDCh8yYWxdk/JYk1Mzst PYpQ==
X-Gm-Message-State: AGi0PubWfwAdxOJyEvy3EaxBgWvC8P+PIqWW8dl7DzJAFjruK/51yefd jtjbmpTJn9xTFASIXozecUSzqCnbFPypzPi/rcLtLEYGKGYxvp4sjP+YHgS9Y0/BsFR3AuaWjvi 6dqWK6BQhcAZ7vbGDWnXt6g==
X-Received: by 2002:ad4:4507:: with SMTP id k7mr2880674qvu.40.1586478850906; Thu, 09 Apr 2020 17:34:10 -0700 (PDT)
X-Google-Smtp-Source: APiQypJFCjQfanFyAvOqGLhwWChwPMXPTFeyYGb0wFDe7oUFvNfy9PketNBzjB6ApdovjXQW+PSrkQ==
X-Received: by 2002:ad4:4507:: with SMTP id k7mr2880650qvu.40.1586478850549; Thu, 09 Apr 2020 17:34:10 -0700 (PDT)
Received: from turing-police ([2601:5c0:c001:c9e1::359]) by smtp.gmail.com with ESMTPSA id e26sm379071qto.90.2020.04.09.17.34.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 09 Apr 2020 17:34:09 -0700 (PDT)
Sender: Valdis Kletnieks <valdis@vt.edu>
From: "Valdis Kl=?utf-8?Q?=c4=93?=tnieks" <valdis.kletnieks@vt.edu>
X-Google-Original-From: "Valdis Kl=?utf-8?Q?=c4=93?=tnieks" <Valdis.Kletnieks@vt.edu>
X-Mailer: exmh version 2.9.0 11/07/2018 with nmh-1.7+dev
To: Timo Sirainen <timo@sirainen.com>
Cc: ietf-smtp@ietf.org
In-Reply-To: <8CF389F4-7BD3-44D0-85F4-91E66120A59B@sirainen.com>
References: <8CF389F4-7BD3-44D0-85F4-91E66120A59B@sirainen.com>
Mime-Version: 1.0
Content-Type: multipart/signed; boundary="==_Exmh_1586478848_57256P"; micalg=pgp-sha1; protocol="application/pgp-signature"
Content-Transfer-Encoding: 7bit
Date: Thu, 09 Apr 2020 20:34:08 -0400
Message-ID: <272440.1586478848@turing-police>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-smtp/-EDZlNMkK4Gw9pLDqBSY-CdV7Xc>
Subject: Re: [ietf-smtp] SMTP server reply extensions
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: Fri, 10 Apr 2020 00:34:19 -0000

On Wed, 08 Apr 2020 17:00:27 +0300, Timo Sirainen said:

> 2. Single instance storage for deliveries between backends in a cluster

> The idea is that if backends share a storage (NFS, object storage) and there
> are multiple recipients, the proxy could deliver mail first to backend1, get
> back some metadata and use that to deliver mail to backend2, which would use
> the metadata to store a copy of the original mail. So for example:

> And then in backend2:
> RCPT TO:<user2@example2.com> MAILDATA /nfs/mail/user1@example.com/INBOX/Maildir/file1

> Now backend2 can create a hard link from user1@example.com's mail to
> user2@example2.com's INBOX, saving some disk space. (Obviously only if the
> mails would be identical.)

Maybe I need more caffeine, but I'm pretty convinced you'll have a hard time
getting identical mails, unless the front-end -> back-end mail fails to add
a Received: line. There's no way the Received: line for front->backend1 will
be identical to the Received: line for front->backend2.