Re: [ietf-smtp] SMTP server reply extensions

Timo Sirainen <timo@sirainen.com> Fri, 10 April 2020 12:56 UTC

Return-Path: <timo@sirainen.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 736953A08EB for <ietf-smtp@ietfa.amsl.com>; Fri, 10 Apr 2020 05:56:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 GWoHBJRNpFwc for <ietf-smtp@ietfa.amsl.com>; Fri, 10 Apr 2020 05:56:24 -0700 (PDT)
Received: from sirainen.com (mail.sirainen.com [94.237.26.55]) by ietfa.amsl.com (Postfix) with ESMTP id BB58D3A08E5 for <ietf-smtp@ietf.org>; Fri, 10 Apr 2020 05:56:24 -0700 (PDT)
Received: from [172.20.10.2] (unknown [85.76.150.94]) by sirainen.com (Postfix) with ESMTPSA id 002CA2B3C8B; Fri, 10 Apr 2020 12:56:23 +0000 (UTC)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\))
From: Timo Sirainen <timo@sirainen.com>
In-Reply-To: <272440.1586478848@turing-police>
Date: Fri, 10 Apr 2020 15:56:23 +0300
Cc: ietf-smtp@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <7F6BD818-1691-4E8A-8E59-AE86CDF4E3CF@sirainen.com>
References: <8CF389F4-7BD3-44D0-85F4-91E66120A59B@sirainen.com> <272440.1586478848@turing-police>
To: =?utf-8?Q?Valdis_Kl=C4=93tnieks?= <Valdis.Kletnieks@vt.edu>
X-Mailer: Apple Mail (2.3608.60.0.2.5)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-smtp/BNs4hMDNBNB3iY78uKGuHDwSo30>
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 12:56:26 -0000

On 10. Apr 2020, at 3.34, Valdis Klētnieks <Valdis.Kletnieks@vt.edu> wrote:
> 
> 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.

True, I didn't remember that LMTP also normally adds a Received: header. But I don't think it's really necessary to add them, and if this feature is implemented then we could just require turning them off in backends. It's just an internal implementation detail how the mails are delivered after MTA has accepted them. I know some of our customers already have disabled the Received headers because they don't want any of the internal server names visible in the mails. All the tracing information exists in the log files anyway.